Hierarchical adaptive closed-loop fluid resuscitation and cardiovascular drug administration system

ABSTRACT

The present disclosure describes a closed-loop fluid resuscitation and/or cardiovascular drug administration system that uses continuous measurements and adaptive control architecture. The adaptive control architecture uses a function approximator to identify unknown dynamics and physiological parameters of a patient to compute appropriate infusion rates and to regulate the endpoint of resuscitation.

CROSS REFERENCE

This application is a Continuation application of U.S. patentapplication Ser. No. 17/731,347, filed Apr. 28, 2022, which applicationis a Continuation application of U.S. patent application Ser. No.17/090,729, filed Nov. 5, 2020, which published as U.S. ApplicationPublication No. 2021/0128832 on May 6, 2021. The '729 Application is aContinuation application of U.S. patent application Ser. No. 16/680,145,filed Nov. 11, 2019, which issued as U.S. Pat. No. 10,926,031 on Feb.23, 2021. The '145 Application is a Continuation-in-Part (CIP)application of International Application No. PCT/US2018/032369, filedMay 11, 2018, which published on Nov. 15, 2018 as International PatentApplication Publication No. WO2018/209268, and which PCT applicationclaims priority to and the benefit of the filing date of U.S.Provisional Application No. 62/505,232, filed May 12, 2017. All of theforegoing applications are hereby incorporated herein by reference intheir entireties.

GOVERNMENT RIGHTS

The invention was made with government support under W81XWH-14-C-1385 bythe US Army Medical Research and Material Command, under IIP-1648292 bythe National Science Foundation, and under IIP-1831225 by the NationalScience Foundation. The government has certain rights in the invention.

BACKGROUND

Reliable and consistent fluid resuscitation (i.e., intravenousadministration of fluids) is critical for perioperative and intensivecare unit (ICU) fluid management in human and animal populations. Thegoal of fluid resuscitation is to restore blood volume in thecirculatory system to an acceptable level to ensure adequate tissueperfusion. However, large intra-patient and inter-patient variability inphysiological parameters, and the effects of different illnesses andmedications can result in under-resuscitation and over-resuscitation ofpatients.

INCORPORATION BY REFERENCE

Each patent, publication, and non-patent literature cited in theapplication is hereby incorporated by reference in its entirety as ifeach was incorporated by reference individually.

SUMMARY OF THE INVENTION

In some embodiments, the disclosure provides a method for fluidresuscitation and/or cardiovascular drug administration comprising: a)initiating an infusion rate of a fluid and/or a cardiovascular drug intoa subject at an infusion rate; b) receiving hemodynamic sensor data ofthe subject from at least one medical monitoring device attached to thesubject by a hierarchical control architecture system, wherein thehierarchical control architecture system comprises: at least oneadaptive controller; and a logic-based controller; wherein the subject'shemodynamic data is received by the logic-based controller and the atleast one adaptive controller, wherein the at least one adaptivecontroller and the logic-based controller are in communication with oneanother; c) generating by the at least one adaptive controller analtered infusion rate based on the subject's hemodynamic data, previousinfusion rates, and internal parameters and states of the at least oneadaptive controller; d) verifying by the logic-based controller that thesubject's hemodynamic data and the at least one adaptive controllerstates do not violate rules governing the operation of the at least oneadaptive controller; e) sending the altered infusion rate from thelogic-based controller to at least one infusion pump; f) automaticallyadministering by the at least one infusion pump the fluid and/orcardiovascular drug to the subject at the altered infusion rate orinfusion rates upon receipt of the infusion rate or infusion rates; andg) repeating steps b)-f) at set time intervals.

In some embodiments, the disclosure provides a method for fluidresuscitation and/or cardiovascular drug administration clinicaldecision support comprising: a) asking a user to provide an initialinfusion rate of a fluid and/or a cardiovascular drug; b) receivinghemodynamic sensor data of the subject from at least one medicalmonitoring device attached to the subject by a hierarchical controlarchitecture system, wherein the hierarchical control architecturesystem comprises: at least one adaptive controller; and a logic-basedcontroller; wherein the subject's hemodynamic data is received by thelogic-based controller and the at least one adaptive controller, whereinthe at least one adaptive controller and the logic-based controller arein communication with one another; c) generating by the at least oneadaptive controller an altered infusion rate based on the subject'shemodynamic data, previous infusion rates, and internal parameters andstates of the at least one adaptive controller; d) verifying by thelogic-based controller that the hemodynamic data and the at least oneadaptive controller states do not violate rules governing the operationof the at least one adaptive controller; e) verifying by the logic-basedcontroller whether the altered infusion rate meets the requirements tonotify the user and if not the infusion rate is kept at the previousvalue; f) displaying the altered infusion rate from the at least oneadaptive controller if the altered infusion rate meets the requirementin step e); g) asking the user to either accept the altered infusionrate or change the new infusion rate to a different value or differentvalues; and h) repeating steps b)-g) at set time intervals.

In embodiments, this disclosure provides for a clinical decision support(semi-automated) system for notifying a user through audio-visual alarmsif certain infusion therapy performance criteria are violated. Anotification can be issued by a higher-level logic-based controller. Insome embodiments, the notification asks the user to change the therapytype from one type to another. For example, in some embodiments, if thesubject was being administered with fluid, the user can be asked toconsider administering a vasopressor.

In another embodiment, this disclosure provides for a clinical decisionsupport system for issuing a prompt when a change in infusion therapy isimplicated based at least on a background infusion rate. An appropriatenotification message and/or an appropriate change in infusion therapyrecommendation message may be determined. Further, the appropriatenotification message and/or the appropriate recommendation message maybe displayed.

In another embodiment, this disclosure provides for an apparatus fordisplaying infusion therapy information which can be used to optimizeinfusion therapy. The apparatus comprises a memory, a display, and aprocessor in operable communication with the memory and the display. Thedisplay displays at least one appropriate notification message andappropriate change in infusion therapy recommendation when the processorissues the notification message and/or the recommendation message uponimplication for a change in infusion therapy based at least on an activeinfusion rate stored in memory and a background infusion rate. In someembodiments, the background infusion rate is calculated by a lower-levelcontroller based at least on received sensor measurement from ahemodynamic monitoring device.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1A is a diagram that illustrates a two-compartment model of fluidexchange in the body for non-burn patients. FIG. 1B is a diagram thatillustrates a three-compartment model of the microvascular exchangesystem for burn patients. FIG. 1C is a diagram that illustrates atwo-compartment model of cardiovascular drug exchange in the body.

FIG. 2A is a diagram that illustrates the overall architecture of afully automated closed-loop fluid resuscitation or cardiovascular drugadministration system. FIG. 2B is a diagram that illustrates the overallarchitecture of a fully automated closed-loop fluid resuscitation andcardiovascular drug administration system.

FIG. 3A is a diagram that illustrates the overall architecture of apartially automated (clinical decision support) fluid resuscitation orcardiovascular drug administration system. FIG. 3B is a diagram thatillustrates the overall architecture of a partially automated (clinicaldecision support) fluid resuscitation and cardiovascular drugadministration system.

FIG. 4A is a diagram that illustrates components of a fully automated,closed-loop fluid resuscitation or cardiovascular drug administrationsystem. FIG. 4B is a diagram that illustrates components of a fullyautomated, closed-loop fluid resuscitation and cardiovascular drugadministration system.

FIG. 5A is a diagram that illustrates components of a partiallyautomated clinical decision support fluid resuscitation orcardiovascular drug administration system. FIG. 5B is a diagram thatillustrates components of a partially automated clinical decisionsupport fluid resuscitation and cardiovascular drug administrationsystem.

FIG. 6 is a flow chart that illustrates the lower-level adaptive controlarchitecture according to embodiments.

FIG. 7 is a graph that depicts exemplary stroke volume variation versustime.

FIG. 8 is a graph that depicts exemplary fluid infusion rates computedby the adaptive control framework.

FIG. 9 is a graph that depicts exemplary plasma volume in circulationversus time.

FIG. 10 is a graph that depicts exemplary changes in filtered SVV (%) in2 canine subjects experiencing controlled hemorrhage.

FIG. 11 is a graph that depicts exemplary changes in infusion rates in 2canine subjects experiencing controlled hemorrhage.

FIG. 12 is a graph that depicts exemplary changes in filtered SVV (%) in3 canine subjects experiencing uncontrolled hemorrhage.

FIG. 13 is a graph that depicts exemplary changes in infusion rates in 3canine subjects experiencing uncontrolled hemorrhage.

FIG. 14 is a graph that depicts exemplary changes in filtered SVV (%) in2 canine subjects that were hypotensive as a result of administration ofsodium nitroprusside (S4-1) and increase in isoflurane (S5-1).

FIG. 15 is a graph that depicts exemplary changes in infusion rates in 2canine subjects that were hypotensive as a result of administration ofsodium nitroprusside (S4-1) and increase in isoflurane (S5-1).

FIG. 16 is a flow chart that illustrates components of the higher-levelcontroller for the closed-loop fluid resuscitation system inembodiments.

FIG. 17 is a flow chart that illustrates components of the higher-levelcontroller for the clinical decision support case in embodiments.

FIG. 18 is a graph that depicts exemplary mean arterial pressure versustime.

FIG. 19 is a graph that depicts exemplary cardiovascular drug infusionrates computed by the adaptive control framework.

FIG. 20 is a graph that depicts exemplary mean arterial pressure versustime.

FIG. 21 is a graph that depicts exemplary fluid infusion rates computedby the adaptive control framework.

FIG. 22 is a graph that depicts exemplary stroke volume variation versustime.

FIG. 23 is a graph that depicts exemplary fluid infusion rates computedby the fluid resuscitation adaptive control framework.

FIG. 24 is a graph that depicts exemplary mean arterial pressure versustime.

FIG. 25 is a graph that depicts exemplary vasopressor infusion ratescomputed by the cardiovascular drug administration adaptive controlframework.

FIG. 26 is a diagram that depicts an embodiment of a fluid resuscitationand cardiovascular drug administration system implemented on hardware.

FIG. 27 is a block diagram illustrating an embodiment of the apparatusfor displaying infusion therapy information for optimizing infusiontherapy.

FIG. 28 is a diagram that depicts an embodiment of the apparatus fordisplaying infusion therapy information for optimizing infusion therapy.

FIG. 29 is a flow chart that illustrates the administration ofpre-approved ranges of infusion rates according to embodiments.

FIG. 30 is a flow chart that illustrates the alarm function to preventunder- or over-administration of fluid and/or drug according toembodiments.

DETAILED DESCRIPTION

Reliable and consistent fluid resuscitation (i.e., intravenousadministration of fluids) is critical for perioperative and intensivecare unit (ICU) fluid management in human and animal populations. Fluidmanagement is required for surgical patients as well as patientssuffering from hypovolemia, sepsis, severe sepsis, septic shock, burn,and other conditions. The goal of fluid resuscitation is to restoreblood volume in the circulatory system to an acceptable level in orderto ensure adequate tissue perfusion (i.e., blood delivery to tissue).However, large intra-patient and inter-patient variability inphysiological parameters, and the effects of different illnesses andmedications can result in under-resuscitation and over-resuscitation ofpatients.

Under-resuscitation results in hypovolemia, which can lead tohypoperfusion and organ failure. Over-resuscitation results in fluidoverload, which can lead to complications such as pulmonary edema. Fluidoverload is associated with higher rates of morbidity and mortality.Restrictive fluid resuscitation protocols reduce the number ofmechanical ventilation days and the length of hospital stays.

Cardiovascular drug administration can be used independently to addressa clinical condition (e.g., vasopressors are used to increase bloodpressure to a clinically acceptable value or inotropic agents are usedto change the contractility of the heart). Cardiovascular drugs, such asvasopressors, are administered independent of fluids in critical carefor hypotensive patients. Cardiovascular drugs can also be used incombination with fluid resuscitation. For example, to addresshypotension and hypovolemia in sepsis and during surgery, a vasopressorand fluid can be administered simultaneously.

The present disclosure describes a reliable and consistent closed-loopfluid resuscitation system, a clinical decision support fluidresuscitation system, a closed-loop cardiovascular drug administrationsystem, a clinical decision support cardiovascular drug administrationsystem, a closed-loop fluid and cardiovascular drug administrationsystem, and a clinical decision support fluid and cardiovascular drugadministration system. The system uses continuous measurements fromstandard operating room (OR) or ICU hemodynamic monitoring devices orsensors or a built-in or add-on modules to measure such continuousmeasures to compute the required fluid and/or cardiovascular druginfusion rates for patients receiving continuous infusion. Adaptivecontrol architecture is used to compute the required infusion rates toregulate an endpoint of fluid or drug administration including, but notlimited to, static indicators of fluid responsiveness and dynamicindicators of fluid responsiveness for the fluid resuscitation module,and hemodynamic measures for the cardiovascular drug administrationmodule. In some embodiments, the static indicators of fluidresponsiveness include mean arterial pressure, central venous pressure,heart rates, cardiac output, stroke volume, cardiac index, and urineoutput rates of patients. In some embodiments, dynamic indicators offluid responsiveness include stroke volume variation, pulse pressurevariations, systolic pressure variation, dynamic arterial elastance, andpleth variability indices of patients. In some embodiments, hemodynamicmeasures include mean arterial pressure, central venous pressure,systolic pressure, diastolic pressure, heart rate, cardiac output,cardiac index, systemic vascular resistance, stroke volume, and urineoutput. The closed-loop fluid resuscitation and/or cardiovascular drugadministration system described herein comprises an adaptive controlleror two adaptive controllers that use a function approximator, such as aneural network, Fourier functions, or wavelets, to identify the unknowndynamics and physiological parameters of a patient to computeappropriate infusion rates and to regulate the endpoint of fluidresuscitation or cardiovascular drug administration.

The developed fluid resuscitation system can use either crystalloids orcolloids during resuscitation and use vasoactive cardiovascular drugs(e.g., vasopressor) or inotropic agents. The fluid infusion rate (e.g.,in mL/hour) is highly dependent on a patient needs. In some embodiments,the fluid infusion rate can range from 0 to 3,000 mL/hr or more inhumans, and 0 to 40,000 mL/h or more in animals. The cardiovascular druginfusion rate (e.g., in mcg/kg/min) is highly dependent on a patient'sneeds. In some embodiments, the cardiovascular drug infusion rate (e.g.,vasopressor or inotropic agents) can range from 0 mcg/kg/min to 40mcg/kg/min, or can exceed 40 mcg/kg/min.

Any method or algorithm described herein can be embodied in software orset of computer-executable instructions capable of being run on acomputing device or devices. The computing device or devices can includeone or more processor (CPU) and a computer memory. The computer memorycan be or include a non-transitory computer storage media such as RAMwhich stores the set of computer-executable (also known herein ascomputer readable) instructions (software) for instructing theprocessor(s) to carry out any of the algorithms, methods, or routinesdescribed in this disclosure. As used in the context of this disclosure,a non-transitory computer-readable medium (or media) can include anykind of computer memory, including magnetic storage media, opticalstorage media, nonvolatile memory storage media, and volatile memory.Non-limiting examples of non-transitory computer-readable storage mediainclude floppy disks, magnetic tape, conventional hard disks, CD-ROM,DVD-ROM, BLU-RAY, Flash ROM, memory cards, optical drives, solid statedrives, flash drives, erasable programmable read only memory (EPROM),electrically erasable programmable read-only memory (EEPROM),non-volatile ROM, and RAM. The computer-readable instructions can beprogrammed in any suitable programming language, including JavaScript,C, C#, C++, Java, Python, Perl, Ruby, Swift, Visual Basic, and ObjectiveC. Embodiments of the invention also include a non-transitory computerreadable storage medium having any of the computer-executableinstructions described herein.

A skilled artisan will further appreciate, in light of this disclosure,how the invention can be implemented, in addition to software andhardware, using one or more firmware. As such, embodiments of theinvention can be implemented in a system which includes any combinationof software, hardware, or firmware. In the context of thisspecification, the term “firmware” can include any software programmedonto the computing device, such as a device's nonvolatile memory. Thus,systems of the invention can also include, alternatively or in additionto the computer-executable instructions, various firmware modulesconfigured to perform the algorithms of the invention.

According to embodiments, the computing device or devices can include amainframe computer, web server, database server, desktop computer,laptop, tablet, netbook, notebook, personal digital assistant (PDA),gaming console, e-reader, smartphone, or smartwatch, which may includefeatures such as a processor, memory, hard drive, graphics processingunit (GPU), and input/output devices such as display, keyboard, andmouse or trackpad (depending on the device). Embodiments can alsoprovide a graphical user interface made available on one or more clientcomputers. The graphical user interface can allow a user on a clientcomputer remote access to the method or algorithm.

Additional embodiments of the invention can include a networked computersystem for carrying out one or more methods of the invention. Thecomputer system can include one or more computing devices which caninclude a processor for executing computer-executable instructions, oneor more databases, a user interface, and a set of instructions (e.g.software) for carrying out one or more methods of the invention.According to other embodiments, the computing device or devices can beconnected to a network through any suitable network protocol such as IP,TCP/IP, UDP, or ICMP, such as in a client-server configuration and oneor more database servers. The network can use any suitable networkprotocol and can be any suitable wired or wireless network including anylocal area network, wide area network, Internet network,telecommunications network, Wi-Fi enabled network, or Bluetooth enablednetwork.

Compartmental Modeling for Characterizing Fluid Distribution

The present disclosure models the microvascular exchange system tocharacterize the distribution of fluids in the body.

A two-compartment dynamic system model is used for all patientpopulations except for patients with burn injuries. The compartments fortwo-compartment dynamic system models include circulation (blood) andinterstitial tissue. A 4th-order nonlinear state space modelrepresentation of the dynamic system can provide a simplified model ofthe microvascular exchange system for non-burn patients. The states ofthe two-compartment dynamic system include the volume of fluids andalbumin mass in each compartment (a total of four states).

A three-compartment model is used for patients with burn injuries. Thestates of the three-compartment dynamic system model include circulation(blood), injured tissue, and uninjured tissue. A 6th-order nonlinearstate space model representation of the dynamic system can provide asimplified model of the microvascular exchange system for burn patients.The states of the three-compartment dynamic system include volume offluids and albumin mass in each compartment (a total of six states).

The parameters of the two- and three-compartment models of themicrovascular exchange system characterize fluid and mass exchangebetween different compartments. These parameters are generally unknownand are different from patient to patient.

FIG. 1A illustrates a two-compartment model of the fluid exchange in thebody for non-burn patients. FIG. 1B illustrates a three-compartmentmodel of the microvascular exchange system for burn patients.

In some embodiments, a higher number of compartments are used to modelthe microvascular exchange system of a patient population. In someembodiments, a model dynamic system consists of 2, 3, 4, or 5compartments. In some embodiments, a 1, 2, 3, or 4-compartment dynamicsystem model is used for a patient population. In some embodiments, atwo-compartment dynamic system model is used for a patient population.In some embodiments, a three-compartment dynamic system model is usedfor a patient population. In some embodiments, a four-compartmentdynamic system model is used for a patient population.

Compartmental Modeling for Characterizing Cardiovascular DrugDistribution

The present disclosure models the cardiovascular drug distribution inthe body using a compartmental model.

Cardiovascular drug distribution can be modeled using a two-compartmentmodel. The compartments for two-compartment dynamic system modelsinclude circulation (blood) and tissue. A 2nd-order nonlinear statespace model representation of the dynamic system can provide asimplified model of the cardiovascular drug distribution for patients.The states of the two-compartment dynamic system include theconcentration of cardiovascular drug in each compartment.

The parameters of the two-compartment model of the cardiovascular drugdistribution characterizes cardiovascular drug mass exchange betweendifferent compartments. These parameters are generally unknown and aredifferent from patient to patient. FIG. 1C illustrates a two-compartmentmodel of the cardiovascular drug distribution in the body.

In some embodiments, a higher number of compartments are used to modelthe cardiovascular drug distribution for a patient. In some embodiments,a model dynamic system consists of 2, 3, 4, or 5 compartments. In someembodiments, a 1, 2, 3, or 4-compartment dynamic system model is usedfor a patient population. In some embodiments, a two-compartment dynamicsystem model is used for a patient population. In some embodiments, athree-compartment dynamic system model is used for a patient population.In some embodiments, a four-compartment dynamic system model is used fora patient population.

Process for Computing Fluid Infusion Rate and/or Cardiovascular DrugInfusion Rate for a Closed-Loop System or a Clinical Decision SupportSystem

The disclosure provides an adaptive control architecture framework for aclosed-loop fluid resuscitation and/or cardiovascular drugadministration system. The fluid resuscitation and/or cardiovasculardrug administration system of the disclosure receives data from amonitoring system or a set of monitoring systems. In some embodiments,the fluid resuscitation and/or cardiovascular drug administration systemreceives data from an existing monitoring system or systems. In someembodiments, the fluid resuscitation and/or cardiovascular drugadministration system receives data from a built-in monitoring system orsystems. In some embodiments, the fluid resuscitation and/orcardiovascular drug administration system receives data from an add-onmonitoring system or systems.

The received data comprises one of: blood pressure, heart rate, strokevolume variation, pulse pressure variation, dynamic arterial elastance,pleth variability index, urine output rate, systolic pressure variation,central venous pressure, mean arterial pressure, cardiac output, cardiacindex, systolic pressure, diastolic pressure, systemic vascularresistance, or stroke volume. In some embodiments, the received datacomprises a combination of blood pressure, heart rate, stroke volumevariation, pulse pressure variation, dynamic arterial elastance, plethvariability index, urine output rate or urine output, systolic pressurevariation, central venous pressure, mean arterial pressure, cardiacoutput, cardiac index, systolic pressure, diastolic pressure, systemicvascular resistance, or stroke volume. In some embodiments, a built-inor add-on monitoring system or systems are used and the input dataincludes one or a combination of an invasive blood pressure signal or anon-invasive pressure signal collected from a patient's arm or leg usinga blood pressure cuff.

The disclosed fluid resuscitation and/or cardiovascular drugadministration system can transmit data to a receiver or a set ofreceivers. In some embodiments, the disclosed fluid resuscitation and/orcardiovascular drug administration system can transmit data to anexternal or built-in infusion pump or infusion pumps, a user, anelectronic medical record, or a remote location. In some embodiments,the disclosed fluid resuscitation and/or cardiovascular drugadministration system can transmit data to a combination of receivers.In some embodiments, the disclosed fluid resuscitation and/orcardiovascular drug administration system can transmit data to aninfusion pump or infusion pumps and a user or users. In someembodiments, the disclosed fluid resuscitation system can transmit datato an infusion pump or infusion pumps, a user or users, and an electricmedical record. In some embodiments, the disclosed fluid resuscitationsystem can transmit data to an infusion pump or infusion pumps, a useror users, an electronic medical record, and a remote location.

The adaptive architecture of the disclosure can be implemented in afully automated architecture or a partially automated architecture.

Full automation: In some embodiments, the adaptive architecture of thedisclosure is implemented in a fully automated architecture, wherein theinfusion rate of the infusion pump or infusion rates of the infusionpumps are updated automatically by the system using the most recentvalue of the infusion rate or infusion rates.

Partial automation (also referred to as clinical decision support): Insome embodiments, the adaptive architecture of the disclosure isimplemented in a partially automated architecture. In some embodiments,the framework of the disclosure is used within a clinical decisionsupport context, where recommended infusion rates are displayed to theend-user (clinician) for approval. In some embodiments, the system canrequest for approval before changing the infusion rate of the pump orpumps. In some embodiments, the end-user can use recommended infusionrate changes and manually change the infusion rate on the pump or pumpsbased on his/her clinical judgment and the recommendation provided bythe clinical decision support system. In some embodiments, the end-usercan enter whether the recommended infusion rate was accepted orrejected. In some embodiments, the end-user can enter a new manuallychanged infusion rate or infusion rates. In some embodiments, the systemcan automatically change the infusion rate of the pump or infusion ratesof the pump after the user approves or modifies the recommended infusionrate or infusion rates.

Architecture of the Disclosure

The present disclosure is able to determine suitable infusion ratesbased on an input from patient-monitoring devices, built-in monitoringdevices, add-on monitoring modules, or sensors. Infusion rates can beadjusted based on the input from patient-monitoring devices, built-inmonitoring devices, add-on monitoring modules, or sensors. The adaptivecontrol framework of the disclosure does not require anypatient-specific information (e.g., age, gender, weight, diagnosis).Furthermore, the framework does not require an accurate model of thepatient dynamics and the patient-specific physiological parameters.

The present disclosure describes a closed-loop or clinical decisionsupport fluid resuscitation and/or cardiovascular drug administrationsystem predicated on hierarchical adaptive control architecture. In someembodiments, the hierarchical control architecture is composed of one ortwo lower-level adaptive controllers and a higher-level, logic-basedcontroller. In some embodiments, the higher-level, logic-basedcontroller is a rule-based expert system.

If the system is used for fluid resuscitation, the hierarchical controlarchitecture is composed of an adaptive controller fluid module and ahigher-level, logic-based controller. If the system is used for onlycardiovascular drug administration, the hierarchical controlarchitecture is composed of an adaptive controller cardiovascular drugmodule and a higher-level, logic-based controller. If the system is usedfor fluid resuscitation and cardiovascular drug administration, thehierarchical control architecture is composed of an adaptive controllerfluid module, an adaptive controller cardiovascular drug module, and ahigher-level, logic-based controller.

The lower-level controller focused on fluid resuscitation uses anadaptive control framework to regulate a measure of fluid responsivenessto a desired value by adjusting the fluid infusion rate. In someembodiments, the lower-level controller can regulate mean arterialpressure, systolic pressure, diastolic pressure or a measure of fluidresponsiveness including stroke volume variation, pleth variabilityindex, pulse pressure variation, dynamic arterial elastance, centralvenous pressure, urine output rate or urine output, or systolic pressurevariation. While the goal of this lower-level controller is to regulatea measure of fluid responsiveness to a desired value, the controller mayachieve a measurement that is close to the desired value (with someerror). Lower-level controller design parameters can be changed toadjust the value of this error.

The lower-level controller focused on cardiovascular drug administrationuses an adaptive control framework to regulate a hemodynamic measure toa desired value by adjusting the cardiovascular drug infusion rate. Insome embodiments, the lower-level controller can regulate mean arterialpressure, systolic pressure, diastolic pressure, heart rate, cardiacoutput, stroke volume, systemic vascular resistance, or cardiac index.In some embodiments the administered cardiovascular drug is avasopressor and the lower-level controller can regulate mean arterialpressure, systolic pressure, systemic vascular resistance, or diastolicpressure. In some embodiments, the administered cardiovascular drug isan inotropic agent and the lower-level controller can regulate cardiacoutput, cardiac index, mean arterial pressure, systemic vascularresistance, or heart rate. In some embodiments, the administeredcardiovascular drug is a chronotropic agent, and the lower-levelcontroller can regulate heart rate or cardiac output. While the goal ofthis lower-level controller is to regulate a hemodynamic measure to adesired value, the controller may achieve a measurement that is close tothe desired value (with some error). Lower-level controller designparameters can be changed to adjust the value of this error.

The role of the higher-level, logic-based controller is differentdepending on whether the system is used to fully automate or partiallyautomate fluid resuscitation and/or cardiovascular drug administration.The higher-level, logic-based controller monitors the performance of thelower-level adaptive controller(s) and the patient's response totherapy. In case of fluid management, a measure of fluid responsivenessor tissue perfusion is monitored (e.g., mean arterial pressure, strokevolume variation, pulse pressure variation, systolic pressure variation,dynamic arterial elastance, pleth variability index etc.) and in case ofcardiovascular drug administration, a measure of hemodynamic function ismonitored (e.g., mean arterial pressure, heart rate etc.). If certainperformance criteria are violated, then the higher-level controller can“disengage” the lower-level controller(s) (if the system is used forfull automation of fluid resuscitation) or the higher-level controllerwill stop providing suggested infusion rates and will alert the end-user(if the system is used for partial automation of fluid resuscitation).Time stamps, infusion rates and measurement data can be sent to aninternal or external database by the higher-level controller forarchiving purposes.

The higher-level controller can also determine the timing of engagingeach lower-level controller. In some embodiments, the higher-levelcontroller engages the fluid resuscitation module first, and if someperformance criteria is not met after a period of time, the drugadministration module is also engaged. The higher-level controller (inclinical decision support) can also determine the when to notify theuser. In some embodiments, the higher-level controller notifies the useronly if the difference between the newly computed infusion rate by thelower-level controller and the last user-approved infusion rate ishigher than some threshold.

In some embodiments, in a partial automation application, thehigher-level controller can use end-user response (to accept or rejectthe suggested infusion rate) to update the internal state of thelower-level controller. In addition, in both full automation and partialautomation, the higher-level controller can change the internal statesof the lower-level controller(s) if the computed infusion rate is out ofa “safe” range defined by the end-user. In some embodiments, if theinfusion rate computed by the lower-level controller exceeds the maximumallowable infusion rate then the higher-level controller resets theinternal parameters and variables of the controller to preset defaultvalues.

The higher-level controller can also provide recommendation to the userto engage the cardiovascular drug administration module if a patient'shemodynamic variable of interest is not improved after a certain periodof time after fluid resuscitation. In some embodiments, the higher-levelcontroller asks the user to engage the fluid resuscitation module first,and if some performance criteria is not met after a period of time, asksthe user to engage the drug administration module. In some embodiments,the higher-level controller asks the user to engage the cardiovasculardrug administration module first, and if some performance criteria isnot met after a period of time, asks the user to engage the fluidresuscitation module.

FIG. 2A illustrates the overall architecture of a fully automatedclosed-loop fluid resuscitation system or a fully automated closed-loopcardiovascular drug administration system of the disclosure. A sensor(e.g., hemodynamic monitor) sends data to the lower-level controller andthe higher-level controller. The higher-level controller monitors theperformance of the lower-level controller and the response of thepatient to fluids or cardiovascular drugs by monitoring measurementsfrom the sensor, internal state of the lower-level controller, andinfusion rate computed by the lower-level controller (which is sent tothe infusion pump by the higher-level controller). The lower-levelcontroller can send or receive data from the higher-level logiccontroller.

The higher-level controller can send or receive data from thelower-level controller. The human user (clinician) can interact with theclosed-loop system through a user interface to set a target value forthe measurement (e.g., set target stroke volume variation of 13% or setmean arterial pressure of 65 mmHg), set the range of “safe” infusionrates (e.g., between 0 and 3,000 mL/hr for fluids or 0 and 0.5mcg/kg/min for a vasopressor), start and stop the system, or set abackup infusion rate in case of loss of sensor signal (e.g., 1,000 mL/hrfor fluid or 0.2 mcg/kg/min for vasopressor). The lower-level controllerprocesses a patient's data received from a sensor or a hemodynamicmonitoring device (external or built-in), and sends computed infusionrates to the higher-level controller. The higher-level controllerensures that the infusion rate meets all requirements (e.g., it is inthe safe range) and if so sends a command to an infusion pump (externalor built-in), which administers fluids or cardiovascular drugs to thepatient.

FIG. 2B illustrates the overall architecture of a fully automatedclosed-loop fluid resuscitation system and cardiovascular drugadministration system of the disclosure. In this system, the closed-loopsystem provides both fluid and cardiovascular drug simultaneously. Oneor two sensors (e.g., hemodynamic monitor and vital sign monitor) senddata to the lower-level controller fluid module and lower-levelcontroller cardiovascular drug module and the higher-level controller.The higher-level controller monitors the performance of the lower-levelcontrollers and the response of the patient to fluid and cardiovasculardrug by monitoring measurements from the sensors, internal state of thelower-level controllers, and infusion rates computed by the lower-levelcontrollers (which are sent to two different infusion pumps by thehigher-level controller: a fluid infusion pump and a cardiovascular druginfusion pump). Lower-level controllers can send or receive data fromthe higher-level logic controller.

The higher-level controller can send or receive data from thelower-level controllers. The human user (clinician) can interact withthe closed-loop system through a user interface to set a target valuefor the measurement or measurements (e.g., set target stroke volumevariation of 13% and mean arterial pressure of 65 mmHg), set the rangeof “safe” infusion rates (e.g., between 0 and 3,000 mL/hr for fluids and0 and 0.5 mcg/kg/min for a vasopressor), start and stop the system, orset a backup infusion rate in case of loss of sensor signal (e.g., 1,000mL/hr for fluid and 0.2 mcg/kg/min for vasopressor). The lower-levelcontrollers process patient's data received from one or more sensors ora hemodynamic monitoring devices (external or built-in), and sendscomputed infusion rates to the higher-level controller. The higher-levelcontroller ensures that the infusion rate meets all requirements (e.g.,they are in the safe range) and if so sends a commands to infusion pumps(external or built-in), which administer fluids and cardiovascular drugsto the patient. Data measured from sensors used by the lower-level fluidmodule and lower-level cardiovascular drug administration module may bethe same (e.g., mean arterial pressure for both modules) or different(e.g., stroke volume variation for fluid module and mean arterialpressure for cardiovascular drug module).

FIG. 3A illustrates the overall architecture of a partially automated(clinical decision support) fluid resuscitation or cardiovascular drugadministration system of the disclosure. A monitoring device or sensor(e.g., hemodynamic monitor, vital sign monitor, urometer, etc.) sendsdata to the lower-level controller and the higher-level controller. Thehigher-level controller monitors the performance of the lower-levelcontroller and the response of the patient to fluids or cardiovasculardrugs by monitoring measurements from the sensor, internal state of thelower-level controller, and infusion rate computed by the lower-levelcontroller and the action taken by the human user (clinician). Thelower-level controller can send or receive data from the higher-levellogic controller. The higher-level controller can send or receive datafrom the lower-level controller.

The human user can interact with the partially automated (clinicaldecision support) system through a user interface to set a target valuefor the measurement (e.g., set target stroke volume variation of 13% orset target mean arterial pressure of 65 mmHg), set the range of “safe”infusion rates (e.g., between 0 and 3,000 mL/hr for fluid or 0 to 0.5mcg/kg/min for vasopressor), and start and stop the system. Thelower-level controller can process a patient's data received from asensor or a hemodynamic monitoring device (external or built-in), andsend recommended infusion rates to the user interface to be displayed.The human user can then either accept or change the recommended rate toan acceptable value. The human user can then manually change theinfusion rate on the pump (if pump is not built-in or a pump that is notconnected to the system by wire or wireless connection) or instruct thesystem to change the infusion rate (for built-in or a pump that isconnected to the system by wire or wireless connection).

FIG. 3B illustrates the overall architecture of a partially automated(clinical decision support) fluid resuscitation and cardiovascular drugadministration system of the disclosure. In this architecture fluid andcardiovascular drug is administered simultaneously. A monitoring deviceor sensor or two monitoring devices and sensors (e.g., hemodynamicmonitor, vital sign monitor, urometer) sends data to the lower-levelcontroller fluid module and a lower-level controller cardiovascular drugmodule and the higher-level controller. The higher-level controllermonitors the performance of the lower-level controllers and the responseof the patient to fluids and cardiovascular drugs by monitoringmeasurements from the sensor or sensors, internal state of thelower-level controllers, and infusion rate computed by the lower-levelcontrollers and the action taken by the human user (clinician).Lower-level controllers can send or receive data from the higher-levellogic controller. The higher-level controller can send or receive datafrom the lower-level controllers.

The human user can interact with the partially automated (clinicaldecision support) system through a user interface to set a target valuefor the measurement or measurements (e.g., set target stroke volumevariation of 13% and set target mean arterial pressure of 65 mmHg), setthe range of “safe” infusion rates (e.g., between 0 and 3,000 mL/hr forfluid and 0 to 0.5 mcg/kg/min for vasopressor), and start and stop thesystem. Lower-level controllers can process patient's data received fromone or more sensors or hemodynamic monitoring devices (external orbuilt-in), and send recommended infusion rates to the user interface tobe displayed. The human user can then either accept or change therecommended rate to an acceptable value. The human user can thenmanually change the infusion rate on the pump, if the pump is notbuilt-in or a pump is not connected to the system by wire or wirelessconnection. The human user can also manually instruct the system tochange the infusion rate for a built-in pump or a pump that is connectedto the system by wire or wireless connection.

FIG. 4A illustrates components of a fully automated, closed-loop fluidresuscitation or cardiovascular drug administration system of thedisclosure. A hemodynamic monitor or sensor sends a patient's data to asensor measurement database. An infusion rate computation engine, whichis embedded in the lower-level controller, retrieves sensor measurementsand computes infusion rates. The infusion rates (and the correspondingsensor measurements) are communicated with an infusion rate database.The infusion rate computation engine can send data to the infusion ratedatabase and an infusion rate verification system. The infusion rateverification system, which is embedded in the higher-level logic-basedcontroller, ensures the computed rates meet the requirements and ifacceptable sends the newly computed infusion rate to the infusion pumpcontroller. The infusion pump controller then automatically changes theinfusion rate of the infusion pump to administer an amount of fluid orcardiovascular drug based on commands received by the infusion pumpcontroller.

FIG. 4B illustrates components of a fully automated, closed-loop fluidresuscitation and cardiovascular drug administration system of thedisclosure. The overall system is composed of two subsystems: asubsystem for fluid management and a subsystem for cardiovascular drugmanagement. In each subsystem, a hemodynamic monitor or sensor sends apatient's data to a sensor measurement database. An infusion ratecomputation engine, which is embedded in the lower-level controller,retrieves sensor measurements and computes infusion rates. The infusionrates and the corresponding sensor measurements are communicated with aninfusion rate database. The infusion rate computation engine can senddata to the infusion rate database and an infusion rate verificationsystem. The infusion rate verification system, which is embedded in thehigher-level logic-based controller, ensures the computed rates meet therequirements and if acceptable sends the newly computed infusion rate tothe infusion pump controller. The infusion pump controller thenautomatically changes the infusion rate of the infusion pump toadminister an amount of fluid or cardiovascular drug based on commandsreceived by the infusion pump controller.

FIG. 5A illustrates components of a partially-automated clinicaldecision support fluid resuscitation or cardiovascular drugadministration system of the disclosure. A hemodynamic monitor or sensorsends a patient's data to a sensor measurement database. An infusionrate computation engine, which is embedded in the lower-levelcontroller, retrieves sensor measurements and computes infusion rates.The infusion rates and the corresponding sensor measurements arecommunicated with an infusion rate database. The infusion ratecomputation engine sends data to the infusion rate verification system,which is embedded in the higher-level logic-based controller. Theinfusion rate verification system ensures the computed rates meet therequirements including the requirement to notify the user of significantchanges in infusion rate and if acceptable notifies the clinician usinga user interface. The recommended new infusion rate is presented to theclinician, who either approves the recommended infusion rate or requestsa modification of the rate based on the clinician's qualitativejudgement. The approved or modified infusion rate is sent to a databasearchiving clinician approved infusion rates. The clinician administersthe approved or modified fluid or cardiovascular drug by either changingthe infusion rate manually, if a pump is not built-in or the pump is notconnected to the system by wire or wireless connection. The cliniciancan also instruct the system to change the infusion rate to the approvedvalue if a pump is built-in or a pump is connected to the system by wireor wireless connection.

FIG. 5B illustrates components of a partially-automated clinicaldecision support fluid resuscitation and cardiovascular drugadministration system of the disclosure. The overall system is composedof two subsystems: a subsystem for fluid management and a subsystem forcardiovascular drug management. In each subsystem, a hemodynamic monitoror sensor sends a patient's data to a sensor measurement database. Aninfusion rate computation engine retrieves sensor measurements andcomputes infusion rates. The infusion rates and the corresponding sensormeasurements are communicated with an infusion rate database. Theinfusion rate computation engine, which is embedded in the lower-levelcontroller, can send data to the infusion rate verification system. Theinfusion rate verification system, which is embedded in the higher-levellogic-based controller, ensures the computed rates meet the requirementsincluding the requirement to notify the user of significant changes ininfusion rate and if acceptable notifies the clinician using a userinterface. The recommended new infusion rates are presented to theclinician, who either approves the recommended infusion rates orrequests a modification of the rates based on the clinician'squalitative judgement. The approved or modified infusion rates are sentto a database archiving clinician approved infusion rates. The clinicianadministers the approved or modified fluid and cardiovascular drug bychanging the infusion rates manually if a pump is not built-in or a pumpthat is not connected to the system by wire or wireless connection. Theclinician can also administer the approved or modified fluid andcardiovascular drug by instructing the system to change the infusionrates to the approved value if a pump is built-in or a pump is connectedto the system by wire or wireless connection.

EXAMPLES Example 1: Computing Fluid or Drug Infusion Rates UsingLower-Level Adaptive Control Architecture

The present disclosure describes a process of computing the fluid orcardiovascular drug infusion rate using lower-level adaptive controlarchitecture. The lower-level adaptive control architecture is appliedto a problem involving only fluid administration, only cardiovascularadministration, or fluid and cardiovascular drug administration. In thecase of a combined fluid and cardiovascular drug administration, twolower-level adaptive controllers running in parallel are implemented tocompute infusion rates for fluid and cardiovascular drug. The fluid orcardiovascular drug infusion rate is computed using lower-level adaptivecontrol architecture through the following steps:

-   -   1) Select a sensor that can measure an endpoint for fluid or        cardiovascular drug administration. For fluid administration,        the endpoint includes variables such as stroke volume variation,        pulse pressure variation, mean arterial pressure, dynamic        arterial elastance, urine output rate, pleth variability index,        dynamic arterial elastance, central venous pressure, systolic        pressure, diastolic pressure, or systolic pressure variation.        For cardiovascular drug administration, the endpoint includes        variables such as mean arterial pressure, cardiac output,        cardiac index, heart rate, systolic pressure, diastolic        pressure, systemic vascular resistance, or central venous        pressure. The values of the sensor are recorded and smoothed        using window averaging or other noise reduction techniques. The        measurements could be performed invasively or non-invasively.    -   2) The controller architecture assumes that a patient is modeled        by an augmented dynamical system model consisting of a 2-, 3-,        or n-compartment model (characterizing fluid or cardiovascular        drug distribution), as well as a fictitious state. The        fictitious state follows the same trend as of the fluid volume        in circulation (in the case of fluid management) or        cardiovascular drug mass in circulation (in the case of        cardiovascular drug management) with some time lag.    -   3) A dynamic observer (estimator) is used to estimate deviation        of the fictitious state and the fluid volume in circulation (in        the case of fluid management) or cardiovascular drug mass in        circulation (in the case of cardiovascular drug management) from        steady state (equilibrium) values.    -   4) A function approximator (e.g., neural network or wavelets        etc.) is used to approximate the unknown dynamics of the patient        and the parameters of the patient, which are modeled by an        augmented dynamical system.    -   5) The function approximator weights (or coefficients), sensor        measurement values, and infusion rate computed by the adaptive        controller at time t−Δt are used to compute a new infusion rate.        Alternatively, the function approximator weights (or        coefficients), sensor measurement values, and infusion rate        computed by the adaptive controller at times t−Δt and t−2Δt are        used to compute a new infusion rate.    -   6) The new infusion rate is sent to higher level controller for        further processing.    -   7) The function approximator weights (or coefficients) are        updated using estimates provided by the dynamic observer, sensor        measurement values, and the infusion rate computed by the        adaptive controller at time t−Δt. Alternatively, the function        approximator weights are updated using estimates provided by the        dynamic observer, sensor measurement values, and the infusion        rate computed by the adaptive controller at times t−Δt and        t−2Δt.    -   8) A delay of T seconds/minutes (e.g., 1 second, 10 seconds, 1        minute, 2 minutes, etc.) is introduced.    -   9) Step 3) is repeated to close the loop.

FIG. 6 details a flow chart of the lower-level adaptive controlarchitecture of the disclosure outlining steps 1)-9).

Example 2: Function Approximation for Modeling Unknown Dynamics andPatient Parameters for Fluid Distribution

A two-compartment model is used to build the closed-loop fluidresuscitation architecture. The same approach is applied forcompartmental models with 3 or more compartments.

A mass balance equation for a two-compartment dynamical system model isgiven by:

{dot over (v)} _(c)(t)=u(t)+J _(L)(t)−J _(t)(t)−J _(urine)(t)−J_(blood)(t), t≥0

{dot over (a)} _(c)(t)=Q _(L)(t)−Q _(t)(t)−a _(blood)(t),

{dot over (v)} _(t)(t)=J _(t)(t)−J _(L)(t)−J _(evaporation)(t),

{dot over (a)} _(t)(t)=−Q _(L)(t)+Q _(t)(t),

where u(t) is the rate of fluid infusion, J_(L)(t) is the rate of volumetransfer from interstitial tissue to circulation, J_(t)(t) is the rateof volume transfer from circulation to interstitial tissue,J_(urine)(t), J_(blood)(t), and J_(evaporation)(t) denote loss of fluidvolume due to urine production, hemorrhage, or evaporation (and othertypes of insensible water loss), respectively. Furthermore, a_(blood)(t)denotes the rate of loss of protein (albumin) mass from hemorrhage,Q_(t)(t) is the rate of albumin mass transfer from circulation tointerstitial tissue, and Q_(L)(t) is the rate of albumin mass transferfrom interstitial tissue to circulation.

The above equation can be rewritten in state space form, namely,

{dot over (v)} _(c)(t)=f ₁(v(t))+g(v(t))u(t), v _(c)(0)=v _(c,0) ,t≥0  (1)

{dot over (a)} _(c)(t)=f ₂(v(t)), a _(c)(0)=a _(c,0)  (2)

{dot over (v)} _(t)(t)=f ₃(v(t)), v _(t)(0)=v _(t,0)  (3)

{dot over (a)} _(t)(t)=f ₄(v(t)), a _(t)(0)=a _(t,0)  (4)

where for t≥0, v(t)=[v_(c)(t), a_(c)(t), v_(t)(t), a_(t)(t)]^(T), andv_(c)(t), a_(c)(t), v_(t)(t), and a_(t)(t) denote fluid volume incirculation, albumin mass in circulation, fluid volume in interstitialtissue, and albumin mass in interstitial tissue, respectively. Inaddition, f₁(v) and f₃(v) denote functions characterizing the rate ofchange of fluid in circulation and tissue compartments, respectively,and f₂(v) and f₄(v) denote functions characterizing the rate of changeof albumin in circulation and tissue compartments, respectively, g(v(t))characterizes the effect of fluid infusion on the compartmental model.Note that variables indicating exchange of volume or mass with theoutside environment including, J_(urine)(t), J_(blood)(t),J_(evaporation)(t), and a_(blood)(t) have been incorporated intofunctions f₁(v), f₂(v), and f₃(v). Note that v_(c,0), a_(c,0), v_(t,0),and a_(t,0) denote volume and albumin mass in circulation andinterstitial tissue at t=0, respectively. Also note that the functionsf₁(v), f₂(v), f₃(v), f₄(v), and g(v) are generally unknown for eachindividual patient.

The original two-compartment model is then modified to introduce acertain structure in the dynamics. A fictitious state, x_(f)(t), isadded such that the fictitious state follows the same trend as thevolume of fluid in circulation, v_(c)(t), with some time lag. Thedynamics of the fictitious state is given by the linear differentialequation

{dot over (x)} _(f)(t)=c ₁ v _(c)(t)+c ₂ x _(f)(t), x _(f)(0)=0,t≥0,  (5)

where c₁, c₂∈R are design parameter. Next, error variables are definedthat quantify the deviation of each variable from its equilibrium state(steady state value). The error variables are defined by equations(6)-(10):

e _(f)(t)=x _(f)(t)−x _(f,e)  (6)

e _(v,c)(t)=v _(c)(t)−v _(c,e)  (7)

e _(a,c)(t)=a _(c)(t)−a _(c,e)  (8)

e _(v,t)(t)=v _(t)(t)−v _(t,e)  (9)

e _(a,t)(t)=a _(t)(t)−a _(t,e)  (10)

where e_(f)(t) denotes the deviation of the fictitious state fromfictitious state equilibrium value x_(f,e), e_(v,c)(t) denotes thedeviation of fluid volume in circulation from its equilibrium valuev_(c,e), e_(a,c)(t) denotes the deviation of albumin mass from itsequilibrium value a_(c,e), e_(v,t)(t) denotes the deviation of fluidvolume in tissue from its equilibrium value v_(t,e), and e_(a,t)(t)denotes the deviation of albumin mass from its equilibrium valuea_(t,e).

It follows from (5) that

$\upsilon_{c,e} = {{- \frac{c_{2}}{c_{1}}}{x_{f,e}.}}$

Hence, (1)-(5) can be rewritten as

ė _(f)(t)=c ₁ e _(v,c)(t)+c ₂ e _(f)(t)  (11)

ė _(v,c)(t)={circumflex over (f)} ₁(e _(v)(t))+ĝ(e _(v)(t))u(t), e_(v,c)(0)=e _(v,c,0) , t≥0  (12)

ė _(a,c)(t)={circumflex over (f)} ₂(e _(v)(t)), e _(a,c)(0)=e_(a,0),  (13)

ė _(v,t)(t)={circumflex over (f)} ₃(e _(v)(t)), e _(v,t)(0)=e _(v,t,0),  (14)

ė _(a,t)(t)={circumflex over (f)} ₄(e _(v)(t)), e _(a,t)(0)=e _(a,t,0),  (15)

where for t≥0, e_(v)(t)=[e_(v,c)(t), e_(a,c)(t), e_(v,t)(t),e_(a,t)(t)], and f₁(v(t)), f₂(v(t)), f₃(v(t)), f₄(v(t)), g(v(t)) arerewritten as {circumflex over (f)}₁(e_(v)(t)), {circumflex over(f)}₂(e_(v)(t)), {circumflex over (f)}₃(e_(v)(t)), {circumflex over(f)}₄(e_(v)(t)), ĝ(e_(v)(t)), respectively, after performing a change ofvariables using equations (6)-(10). Parameters α₁and α₂ are thenintroduced, where α₁, α₂∈R, and equation (12) is rewritten as

ê _(v,c)(t)=α₁ e _(v,c)(t)+α₂ e _(f)(t)+h(ξ(t))+ĝ(e _(v)(t))u(t), e_(v,c)(0)=e _(v,c,0) , t≥0,

where

h(ξ(t))={circumflex over (f)} ₁(e _(v)(t))−α₁ e _(v,c)(t)−α₂ e_(f)(t),  (16)

and

ξ(t)=[e _(v,c)(t),e _(f)(t),e _(a,c)(t),e _(v,t)(t),e _(a,t)(t)]^(T).

Next, a series of basis functions are used, such as neural networksbasis functions (e.g., radial basis functions or sigmoids), wavelets, orFourier functions, to approximate h(ξ) and ĝ(ξ). Specifically,

h(ξ)=w _(p) ^(T)(t)p(ξ)+ε_(p)  (17)

ĝ(ξ)=w _(q) ^(T)(t)q(ξ)+ε_(q)  (18)

wherep₁(ξ), . . . , p_(n) _(p) (ξ) and q₁(ξ), . . . , q_(n) _(q) (ξ) are twosets of basis functions, p(ξ)=[p₁(ξ), . . . , p_(n) _(p) (ξ)]^(T),q(ξ)=[q₁(ξ), . . . , q_(n) _(q) (ξ)]^(T), w_(p)(t)

[w_(p,1)(t), . . . , w_(p,n) _(p) (t)]^(T), and w_(q)(t)

[w_(q,1)(t), . . . , w_(q,n) _(q) (t)]^(T) are time varying weights (orcoefficients) corresponding to the basis functions, and ε_(p) and ε_(q)are the approximation errors.

The presented framework is general; however, for illustration purposes,sigmoidal neural network basis functions of the form

${{s\left( \overset{¯}{\xi} \right)}\overset{\Delta}{=}\frac{1}{1 + e^{\sigma({\overset{¯}{\xi} - {\overset{¯}{\xi}}_{0}})}}},$

σ, t₀∈

, can be used. α₁, α₂, c₁, and c₂ can be selected such that

$\begin{matrix}{{A\overset{\Delta}{=}\begin{bmatrix}c_{2} & c_{1} \\\alpha_{1} & \alpha_{2}\end{bmatrix}},} & (19)\end{matrix}$

is asymptotically stable (i.e., the real parts of all the eigenvalues ofA are negative). One specific choice for these parameters are c₁=100,c₂=−100, α₁=0, and α₂=−100.

Example 3: Function Approximation for Modeling Unknown Dynamics andPatient Parameters for Cardiovascular Drug Distribution

A two-compartment model is used to build the closed-loop cardiovascularadministration architecture disclosed herein. The same approach isapplied for compartmental models with 3 or more compartments.

A drug mass balance equation for a two-compartment dynamical systemmodel is given by:

{dot over (d)} _(c)(t)=u(t)−J _(M)(t)−J _(t)(t)+J _(c)(t)−J _(other)(t),t≥0

{dot over (d)} _(t)(t)=J _(t)(t)−J _(c)(t)

where u(t) is the rate of drug infusion, J_(M)(t) is the rate of drugmass elimination from circulation as a result of metabolism, J_(t)(t) isthe rate of drug mass transfer from circulation to tissue, J_(c)(t) isthe rate of drug mass transfer from tissue to circulation, J_(other)(t)is the rate of drug elimination from circulation other than metabolism(e.g., as a result of hemorrhage).

The above equation can be rewritten in state space form, namely,

{dot over (d)} _(c)(t)=f ₁(d(t))+g(d(t))u(t), d _(c)(0)=d _(c,0) ,t≥0  (20)

{dot over (d)} _(t)(t)=f ₂(d(t)), d _(t)(0)=d _(t,0)  (21)

where for t≥0, d(t)=[d_(c)(t), d_(t)(t)]^(T), and d_(c)(t) and d_(t)(t)denote cardiovascular drug mass in circulation and tissue, respectively.In addition, f₁(d) and f₂(d) denote functions characterizing the rate ofchange of drug mass in circulation and tissue compartments,respectively, g(d(t)) characterizes the effect of cardiovascular druginfusion on the compartmental model. Note that variables indicatingexchange of mass with the outside environment, that is, J_(other)(t),and J_(M)(t), have been incorporated into function f₁(d), and f₂(v).Note that d_(c,0), and d_(t,0), denote drug mass in circulation andtissue at t=0, respectively. Also note that the functions f₁(d), f₂(d),and g(d) are generally unknown for each individual patient.

The original two-compartment model is then modified to introduce acertain structure in the dynamics. A fictitious state, x_(f)(t), isadded such that the fictitious state follows the same trend as thecardiovascular drug mass in circulation, d_(c)(t), with some time lag.The dynamics of the fictitious state is given by the linear differentialequation

{dot over (x)} _(f)(t)=c ₂ d _(c)(t)+c ₁ x _(f)(t), x _(f)(0)=0,t≥0,  (22)

where c₁, c₂∈R are design parameters. Next, error variables are definedthat quantify the deviation of each variable from its equilibrium state(steady state value). The error variables are defined by equations(23)-(26):

e _(f)(t)=x _(f)(t)−x_(f,e)  (23)

e _(d,c)(t)=d _(c)(t)−d _(c,e)  (24)

e _(d,t)(t)=d _(t)(t)−d _(t,e)  (25)

where e_(f)(t) denotes the deviation of the fictitious state fromfictitious state equilibrium value x_(f,e), e_(d,c)(t) denotes thedeviation of cardiovascular drug mass in circulation from itsequilibrium value d_(c,e), and e_(d,t)(t) denotes the deviation ofcardiovascular drug mass in tissue from its equilibrium value d_(t,e).

It follows from (22) that

$d_{c,e} = {{- \frac{c_{1}}{c_{2}}}{x_{f,e}.}}$

Hence, (20)-(22) can be rewritten as

ė _(f)(t)=c ₂ e _(d,c)(t)+c ₁ e _(f)(t)  (26)

ė _(d,c)(t)={circumflex over (f)} ₁(e _(d)(t))+ĝ(e _(d)(t))u(t), e_(d,c)(0)=e _(d,c,0) , t≥0  (27)

ė _(d,t)(t)={circumflex over (f)} ₂(e _(d)(t)), e _(d,t)(0)=e _(d,t,0),  (28)

where for t≥0, e_(d)(t)=[e_(d,c)(t), e_(d,t)(t)], and f₁(d(t)),f₂(d(t)), g(d(t)) are rewritten as {circumflex over (f)}₁(e_(d)(t)),{circumflex over (f)}₂(e_(d)(t)), ĝ(e_(d)(t)), respectively, afterperforming a change of variables using equations (23)-(26). Parametersα₁ and α₂ are then introduced, where α₁, α₂∈R, and equation (12) isrewritten as

ė _(d,c)(t)=α₁ e _(d,c)(t)+α₂ e _(f)(t)+h(ξ(t))+ĝ(e _(d)(t))u(t), e_(d,c)(0)=e _(d,c,0) , t≥0,

where

h(ξ(t))={circumflex over (f)} ₁(e _(d)(t))−α₁ e _(d,c)(t)−α₂ e_(f)(t),  (29)

and

ξ(t)=[ie _(d,c)(t),e _(f)(t),e_(d,t)(t)].

Next, a series of basis functions are used, such as neural networksbasis functions (e.g., radial basis functions or sigmoids), wavelets, orFourier functions, to approximate h(ξ) and ĝ(ξ). Specifically,

h(ξ)=w _(p) ^(T)(t)p(ξ)+ε_(p)  (30)

ĝ(ξ)=w _(q) ^(T)(t)q(ξ)+ε_(q)  (31)

wherep₁(ξ), . . . , p_(n) _(p) (ξ) and q_(q)(ξ), . . . , q_(n) _(q) (ξ) aretwo sets of basis functions, p(ξ)=[p₁(ξ), . . . , p_(n) _(p) (ξ)]^(T),q(ξ)=[q₁(ξ), . . . , q_(n) _(q) (ξ)]^(T), w_(p)(t)

[w_(p,1)(t), . . . , w_(p,n) _(p) (t)]^(T), and w_(q)(t)

[w_(q,1)(t), . . . , w_(q,n) _(q) (t)]^(T) are time varying weights (orcoefficients) corresponding to the basis functions, and ε_(p) and ε_(q)are the approximation errors.

The presented framework is general; however, for illustration purposes,sigmoidal neural network basis functions of the form

${{s\left( \overset{¯}{\xi} \right)}\overset{\Delta}{=}\frac{1}{1 + e^{\sigma({\overset{\_}{\xi} - {\overset{\_}{\xi}}_{0}})}}},$

σ, t₀∈

, can be used. α₁, α₂, c₁, and c₂ can be selected such that

$\begin{matrix}{{A\overset{\Delta}{=}\begin{bmatrix}c_{2} & c_{1} \\\alpha_{1} & \alpha_{2}\end{bmatrix}},} & (32)\end{matrix}$

is asymptotically stable (i.e., the real parts of all the eigenvalues ofA are negative). One specific choice for these parameters are c₁=0.2,c₂=0.013, α₁=0, and α₂=−0.2.

Example 3: Computing the Value of Continuous Infusion

At each time instant t, the infusion rate of the controller (for fluidor cardiovascular drug) is given by

${u(t)} = \left\{ \begin{matrix}{0,{{\hat{u}(t)} \leq 0},} \\{{\hat{u}(t)},{{\hat{u}(t)} > 0},}\end{matrix} \right.$ where${{u(t)} = {{- \frac{1}{1 + {{w_{q}^{T}(t)}{Q\left( {z(t)} \right)}}}}{w_{p}^{T}(t)}{P\left( {z(t)} \right)}}},$and${{{\mathcal{z}}(t)}\overset{\Delta}{=}\left\lbrack {{m\left( {t - {\Delta t}} \right)},{m\left( {t - {2\Delta t}} \right)},{u\left( {t - {\Delta t}} \right)},{u\left( {t - {2\Delta t}} \right)}} \right\rbrack^{T}},$$\begin{matrix}{{P\left( {{\mathcal{z}}(t)} \right)} = {{Q\left( {{\mathcal{z}}(t)} \right)}\overset{\Delta}{=}\left\lbrack {\frac{1}{1 + e^{- {\sigma_{1}({{m({t - {\Delta t}})} - m_{target}})}}},\ldots,\frac{1}{\begin{matrix}{1 +} \\e^{- {\sigma_{n_{node}}({{m({t - {\Delta t}})} - m_{target}})}}\end{matrix}},} \right.}} \\{\frac{1}{1 + e^{- {\sigma_{1}({{m({t - {2\Delta t}})} - m_{target}})}}},\ldots,\frac{1}{\begin{matrix}{1 +} \\e^{- {\sigma_{n_{node}}({{m({t - {2\Delta t}})} - m_{target}})}}\end{matrix}},} \\{\frac{1}{1 + e^{{- \sigma_{1}}{u({t - {\Delta t}})}}},\ldots,\frac{1}{1 + e^{{- \sigma_{n_{node}}}{u({t - {\Delta t}})}}},} \\{\left. {}{\frac{1}{1 + e^{{- \sigma_{1}}{u({t - {2\Delta t}})}}},\ldots,\frac{1}{1 + e^{{- \sigma_{n_{node}}}{u({t - {2\Delta t}})}}}} \right\rbrack,}\end{matrix}$

σ₁, . . . , σ_(node), are sigmoid parameters (e.g., ranging from −100 to100), n_(node) represents the number of nodes of the neural network(e.g., n_(node)=8), and m(t) represents the smoothed (denoised) sensormeasurement used as an endpoint for fluid or drug administration (e.g.,stroke volume variation, urine output rate, mean arterial pressure,central venous pressure, systolic pressure variation, etc. for fluidresuscitation; and mean arterial pressure, heart rate, systolicpressure, diastolic pressure, systemic vascular resistance, centralvenous pressure, etc. for cardiovascular drug administration) at time t.u(t) represents computed infusion rate at time t. For example, smoothed(denoised) sensor measurement can be obtained by a moving window averagewhere the mean value of the sensor measurement in a time window (e.g., 2minutes) is computed and assigned to m(t). Sensor values can bepreprocessed to drop measurements that appear to be noisy or invalid andonly acceptable values are included in the window averaging.

Alternatively,

${{{\mathcal{z}}(t)}\overset{\Delta}{=}\left\lbrack {{m\left( {t - {\Delta t}} \right)},{u\left( {t - {\Delta t}} \right)}} \right\rbrack^{T}},$$\begin{matrix}{{P\left( {{\mathcal{z}}(t)} \right)} = {{Q\left( {{\mathcal{z}}(t)} \right)}\overset{\Delta}{=}\left\lbrack {\frac{1}{1 + e^{- {\sigma_{1}({{m({t - {\Delta t}})} - m_{target}})}}},\ldots,\frac{1}{\begin{matrix}{1 +} \\e^{- {\sigma_{n_{node}}({{m({t - {\Delta t}})} - m_{target}})}}\end{matrix}},} \right.}} \\{\left. {}{\frac{1}{1 + e^{{- \sigma_{1}}{u({t - {\Delta t}})}}},\ldots,\frac{1}{1 + e^{{- \sigma_{n_{node}}}{u({t - {\Delta t}})}}}} \right\rbrack.}\end{matrix}.$

The update laws for the weights are given by the set of ordinarydifferential equations

{dot over (w)} _(p)(t)=β₁Γ(w _(p)(t),−P(z(t))x _(c) ^(T)(t){tilde over(P)}B ₀), w _(p)(0)=w _(p,0) , t≥0,

{dot over (w)} _(q)(t)=β₂Γ(w _(q)(t),−Q(z(t))u(t)x _(c) ^(T)(t){tildeover (P)}B ₀), w _(q)(0)=w _(q,0),

{dot over (x)} _(c)(t)Ax _(c)(t)+L(m(t)−m _(target) −y _(c)(t)), x_(c)(0)=0,

y _(c)(t)=Cx _(c)(t),

where x_(c)(t)=[x_(c,1)(t), x_(c,2)(t)]T represents the estimated valuesof e_(f)(t) and e_(v,c)(t) (in the case of fluid resuscitation) ore_(f)(t) and e_(d,c)(t) (in the case of cardiovascular drugadministration), β₁, β₂>0 denote design parameters (e.g., β₁=0.02 andβ₂=0.04), and representative values for other parameters are given byL=[−1, 0]^(T), B₀=[0, 1]^(T), and C=[−1, 0]^(T). In addition, m_(target)is the desired value for the end point of fluid resuscitation orcardiovascular drug administration (e.g., for fluid resuscitation if thegoal is to maintain a stroke volume variation of 13%, thenm_(target)=13; similarly, for cardiovascular drug administration if thegoal is to maintain a mean arterial pressure of 65 mmHg, thenm_(target)=65), and {tilde over (P)} satisfies the Lyapunov equationgiven by:

(A−LC)^(T) {tilde over (P)}+{tilde over (P)}(A−LC)+{tilde over (R)}=0,  (33)

where {tilde over (R)}>0.

For example, if {tilde over (R)}=I_(2×2) and the parameter values aboveare used, then

$\overset{˜}{P} = \begin{bmatrix}{{0.4}116} & {{0.0}039} \\{{0.0}039} & {2.5}\end{bmatrix}$

for cardiovascular drug administration, and

$\overset{˜}{P} = \begin{bmatrix}{{0.0}005} & {{0.0}03} \\{{0.0}03} & {{0.0}08}\end{bmatrix}$

for fluid resuscitation. In addition, the function Γ(θ, y) is used toensure that controller parameters remain bounded. This function isdefined as:

${\Gamma\left( {\theta,y} \right)}\overset{\Delta}{=}\left\{ \begin{matrix}{y,} & {{{{if}{}{f(\theta)}} < 0},} \\{y,} & {{{{if}{}{f(\theta)}} \geq 0},{{{and}{\nabla f^{T}}y} \leq 0},} \\{{y - {\frac{\nabla f}{{\nabla f}}\left\langle {\frac{\nabla f}{{\nabla f}},y} \right\rangle{f(\theta)}}},} & {{{{if}{}{f(\theta)}} \geq {0{and}{}{\nabla f^{T}}y} > 0},}\end{matrix} \right.$

where f:R^(n)→R is defined as

$\begin{matrix}{{{f(\theta)}\overset{\Delta}{=}\frac{{\left( {\varepsilon_{\theta} + 1} \right)\theta^{T}\theta} - \theta_{\max}^{2}}{\varepsilon_{\theta}\theta_{\max}^{2}}},} & (34)\end{matrix}$

θ_(max)>0, ε_(θ)>0, ∇(.) represents the gradient operator, and ∥.∥represents the Euclidean norm. For example, θ_(max)=1e6 and ε_(θ)=1e−5 .

Example 4: Computer Simulations for Fluid Resuscitation

Adaptive control framework is used to simulate fluid resuscitation of a70 kg patient losing blood at a rate of 2 ml/kg/min at t=0. The goal isto maintain the stroke volume variation measurements at 15%. A Δt of0.001 hour (3.6 seconds) is used for the simulations and β₁=2, β₂=4, andn_(node)=8. The patient model involved a compartmental model to modelfluid distribution and the relationship between volume in circulationand SVV was based on a nonlinear relationship based on experimentalresults on dogs.

FIG. 7 shows stroke volume variation (SVV (%)) versus time. The targetstroke volume variation is 15%. The SVV (%) starts at about 9%, andchanges with the introduction of fluid resuscitation. The SVV (%)increases to the target value of 15%. At t=1 hr, the blood lossincreases to 3 mL/kg/min, and the controller increases the infusion rateto drive stroke volume variation measurements to the target value of15%.

FIG. 8 shows infusion rates computed by the adaptive control framework.The infusion rate is about 700 mL/h at t=0 (start of the simulation).The infusion rate is rapidly increased to about 1500 mL/h to maintain anSVV (%) of 15%. At t=1 hr, the blood loss increases to 3 mL/kg/min, andthe controller increases the infusion rate to about 2250 mL/h tomaintain the target SVV (%) of 15%.

FIG. 9 shows plasma volume in circulation versus time. The plasma volumein circulation rapidly decreases due to loss of blood in spite of fluidresuscitation until reaching an equilibrium value of about 450 mL. Att=1 hr, the blood loss increases to 3 mL/kg/min, and the controllerincreases the infusion rate to drive stroke volume variationmeasurements to the target value of 15%. The plasma volume incirculation remains about the same even after an increase in blood loss.

Example 5: Animal Study for Fluid Resuscitation

The adaptive control framework of the disclosure was used to provideautomated and semi-automated (clinical decision support) fluidresuscitation to five dogs in different hemorrhaging/hypovolemicscenarios.

Five mature intact Beagle dogs, determined to be healthy based on aphysical examination and hemogram, were included in the experiment. Thedogs were individually housed and provided commercial dry dog food andwater ad libitum. Each dog and experiment was identified (Table 1). Forexample, S1-2 represents the second experiment performed on Subject S1.Studies on subjects were performed on different days. Individual trialson the same subject were performed on the same day and a stabilizationperiod was used between trials. All dogs were euthanized with sodiumpentobarbital (100 mg/kg, IV) upon completion of the experiments.

TABLE 1 Study subject information and experiment summary. Subject Weight(kg) Study 1 Study 2 S1 11.6 CH CH S2 7.1 RAH RAH S3 10.8 UH — S4 12.2RH UH S5 9.3 RH UH CH = controlled hypovolemia, UH = uncontrolledhypovolemia, RH = relative hypovolemia, RAH = relative and absolutehypovolemia

Animal Preparation: Food but not water was withheld for 6 hours beforeeach experiment. An intravenous catheter was transcutaneously positionedin the cephalic vein for administration of hydromorphone, 0.15 mg/kg IV.Anesthesia was produced ten minutes later by administering 3.5 to 6mg/kg IV propofol to facilitate orotracheal intubation, and initiallymaintained at a vaporizer setting of 1.5-2% isoflurane in oxygen. Thedogs were positioned on their right side and mechanically ventilated at10-12 breaths/min and 10-14 ml/kg tidal volume in order to maintain theend-tidal partial pressure of carbon dioxide (ET_(CO2)) between 38 and48 mmHg. To avoid potential changes in SVV, tidal volume settings foreach subject was not changed during the study. Esophageal temperaturewas maintained (37° C.) with temperature-controlled warm air blankets.

Vascular catheters were surgically placed in the left jugular vein andright carotid and femoral arteries after perivascular administration of0.5-1.0 ml 2% lidocaine. The carotid or femoral artery catheter wasconnected to a FloTrac sensor with low-compliance fluid filled tubing.The FloTrac sensor was connected to a Vigileo monitor for determinationand continuous monitoring of SVV. The FloTrac sensor was positioned andzeroed at the level of the sternum. The pressure line of the FloTracsensor was flushed with 4 ml/hr of lactated ringer's solution (LRS).Heart rate was determined from a Lead II electrocardiogram (ECG).Criteria for obtaining accurate SVV recordings during mechanicalventilation were employed.

A 5 Fr Swan-Ganz catheter was percutaneously advanced via the rightjugular vein (2 dogs) into the pulmonary artery under fluoroscopicguidance for measurement of cardiac output by thermodilution.Alternatively, cardiac output was determined by a previously implantedflow probe (3 dogs) positioned around the ascending aorta, proximal tobrachio-cephalic trunk for continuous recording of cardiac output.

Experimental Procedures: Five dogs were subjected to 9 experiments.Lactated Ringer's solution (LRS) was administered as fluidresuscitation. A variety of experimental hypovolemic conditions werecreated in order to mimic various clinical conditions (Table 1).Absolute controlled hypovolemia (2 trials) was produced during 1.5minimum alveolar concentration (MAC: 1.27% used throughout) ofisoflurane anesthesia by withdrawing 15 ml/kg/15 minutes from either theright carotid or right femoral artery (S1-1). There was a 30-minutestabilization period between the end of the closed-loop fluidresuscitation (S1-1) and the beginning of the second hemorrhage, 40ml/kg/30 minutes (S1-2). Closed-loop fluid administration was initiatedwithin 10 minutes of completion of each blood withdrawal and continueduntil SVV reached a predetermined target range equal to or less than13±3%.

Absolute uncontrolled hypovolemia (S3-1, S4-2, S5-2; 3 trials), designedto simulate blood loss from a severed artery was produced by withdrawalof approximately 50% (40 ml/kg) of the dogs estimated blood volume (80ml/kg) from the right carotid or right femoral artery over one hour.Five successive 8.0 ml/kg increments of blood were withdrawncontinuously in increments that were completed at approximately 7-8,18-20, 30-32, 43-45, and 60 minutes after initiating hemorrhage.Closed-loop fluid resuscitation was initiated 10 minutes afterinitiation of absolute uncontrolled hypovolemia (i.e., beginning ofStage 2 of blood withdrawal) and continued until SVV reached apredetermined target range equal to or less than 13±3%.

Relative hypovolemia (2 trials) was produced by either increasing theinspired concentration of isoflurane to 2.0-2.5 MAC (S5-1, 1 trial) oradministering sodium nitroprusside (5-10 mcg/kg/min; S4-1, 1 trial)until mean arterial blood pressure was ≤50 mm Hg. The target range SVVwas set at 13±3% for S4-1 and 5±3% for S5-1. Relative and controlledabsolute hypovolemia were produced by increasing the concentration ofisoflurane (0.25-0.5%, 1.5-2.0 MAC multiples) in order to decrease MAPby ≥30% (S2-1, 1 trial) or administering sodium nitroprusside (1-15mcg/kg/min; S2-2, 1 trial) followed by withdrawal of 15 ml/kg/minutes ofblood. The target range SVV was set at 13±3% for S2-1 and S2-2. Thesubject was resuscitated to the target SVV value in S2-1 and stabilizedbefore initiating the second study (S2-2). Fluid resuscitation started15 minutes after achieving relative and controlled absolute hypovolemia.

The closed-loop fluid resuscitation system was employed in a “partialautomation” mode (clinical decision support) in two experimental trials,one involving absolute uncontrolled hemorrhage (S4-2) and one involvingrelative hypovolemia from sodium nitroprusside administration (S4-1),where the system displayed the recommended infusion rate every minuteand the user manually changed the infusion rate. A Horizon NXT ModularInfusion System pump was used in the partial automated mode. While thesystem was able to provide infusion rate recommendations morefrequently, an update interval of 1 minute was chosen to allowsufficient time for the clinical staff to adjust the pump settingsmanually. Measured SVV values were filtered in all studies, includingautomated and partially automated modes, using a 1-minute moving windowaveraging to remove noise. The adaptive controller was implemented usinga neural network with sigmoidal basis functions to use as the functionapproximator.

The subject continuously received a fluid infusion and the controlsystem changed the infusion rate every few seconds in response tochanges in SVV. Vigileo transmitted the most recent value of the SVVmeasurement every 2 seconds using serial communication. The adaptivecontrol framework was implemented on a laptop. The laptop was connectedto the Vigileo using a Serial to USB cable. The closed-loop fluidresuscitation system used a 1-minute moving window averaging to removenoise. The control algorithm was implemented in the Python programminglanguage running on a laptop with the Linux operating system.Measurements from Vigileo were recorded by the laptop using serialcommunication. The closed-loop fluid resuscitation algorithm computed aninfusion rate every 11 seconds using the average SVV values in the past1-minute. The infusion rate was sent by the laptop to an infusion pump(supporting flow rates from 0.06 to 4200 ml/hr) using a USB connection.

Performance Metrics: Performance metrics that are of clinical relevancewere defined in order to assess the performance of the closed-loop fluidresuscitation system. Specifically, T_(target) was defined as theduration from start of fluid administration to restoration of anacceptable SVV target range.

We defined the acceptable SVV target range to be equal to 13±3% with theexception of two experiments, namely, S5-2 (uncontrolled hypovolemia)and S5-1 (relative hypovolemia), where the acceptable SVV target rangewas 10±3% and 5±3%, respectively. The R_(in range) was defined as thepercentage of time that SVV stayed in the acceptable range once SVVtarget range was reached (i.e., duration of time SVV stayed in theacceptable range once SVV target range was reached divided by totalduration of resuscitation). Other performance metrics included minimumand maximum infusion rates denoted by u_(min) and u_(max), respectively,total infused volume to reach the acceptable SVV target range denoted byV_(target), and, in absolute hypovolemia experiments, the ratio of totalfluid volume infused to total blood loss denoted by V_(ratio). To ensurethat the subject can be maintained at the acceptable SVV target range,the resuscitation continued after reaching the acceptable SVV targetrange, and hence, V_(target) and total infused volume are not equal.Continued resuscitation after reaching V_(target) lasted approximately15 minutes on average. The stabilization period between different trialson the same subject started after the completion of the fluidresuscitation of the previous trial.

Controlled Hypovolemia: Absolute hypovolemia during 1.5 MAC isofluraneanesthesia decreased MAP from 100 to 86 mmHg (S-1) and from 109 to 54 mmHg (S1-2) after withdrawal of 15 ml/kg and then 40 ml/kg of bloodrespectively (Table 2). Heart rate increased and cardiac outputdecreased after withdrawal of 15 ml/kg and 40 ml/kg of blood (Table 2).In addition, the SVV increased after withdrawal of 15 ml/kg and 40 ml/kgof blood. The SVV returned to the target range (13%±3) after theadministration of 7 ml/kg and 66 ml/kg of LRS, respectively (Table 2).The total infused volumes were 189 ml (S1-1: V_(ratio)=1.1) and 925 ml(S1-2: V_(ratio)=2), respectively.

TABLE 2 Hemodynamic data and performance metrics for controlledhypovolemia study. Before After Baseline Resuscitation Resuscitationml/kg bled 15 40 15 40 15 40 CO (L/min) 1.5 2.1 1.3 0.8 2.1 1.6 MAP(mmHg) 100 109 86 54 109 63 HR (bpm) 85 108 107 187 108 154 SVV (%) 6 1519 42 13 16 Performance Metrics T_(target) u_(min) u_(max) V_(target)Study (min) (ml/kg/hr) (ml/kg/hr) (ml/kg) S1-1 6.6 26 64 7 (15 ml/kg)S1-2 50.3 70 87 66 (40 ml/kg) T_(target) denotes the duration from startof fluid administration to restoration of an acceptable SVV targetrange, u_(min) and u_(max) denote minimum and maximum infusion rates,respectively, and V_(target) denotes total infused volume to reach theacceptable SVV target range.Uncontrolled Hypovolemia: Closed-loop fluid administration was initiatedduring the second stage of blood withdrawal, and continued throughouthemorrhage (S3-1, S4-2, S5-2). Closed-loop fluid administration wasstopped approximately 30 minutes after the end of the last (fifth) stageof hemorrhage as this exceeds the average time for fluid equilibrationwith the interstitial fluid compartment. Mean arterial blood pressureand cardiac output decreased and heart rate increased during the initial3-4 stages of uncontrolled hypovolemia (Table 3). Heart rate increasedthroughout hemorrhage and remained elevated throughout hemorrhage andfluid administration (Table 3). The SVV increased during the first stageof uncontrolled hypovolemia and returned toward baseline valuesthereafter (Table 3). Total infused volumes for S3, S4, and S5 were1,092 ml (V_(ratio)=2.5), 1,243 ml (V_(ratio)=2.8), and 548 ml(V_(ratio)=1.4), respectively. The fluid administration system was usedin a partially-automated (human-in-the-loop) mode for S4, where therecommended infusion rate was displayed to the user every minute and theuser manually changed the infusion rate to the recommended value.

TABLE 3 Hemodynamic data and performance metrics for uncontrolledhypovolemia study. Baseline Stage 1 Stage 2 Stage 3 Stage 4 Stage 5 EndCO 1.5 0.8 0.8 1.0 0.9 1.0 1.3 (L/min) (1.1-1.7) (0.5-1.5) (0.3-1.4)(0.4-1.4) (0.4-1.7) (0.7-1.7) (1.1-2.0) MAP 81 59 66 65 68 68 59 (mmHg)(62-85) (55-91) (35-87) (45-67) (50-72) (53-78) (44-83) HR 118 134 132132 135 139 137 (bpm) (113-121) (120-171) (108-170) (117-174) (117-170)(116-168) (107-167) SVV (%) 8 21 17 15 14 15 10 (6-12) (17-25) (12-19)(11-16) (11-16) (10-15) (8-18) Performance Metrics u_(min) u_(max)R_(in range) Dog (ml/kg/hr) (ml/kg/hr) (%) S3-1 44 115  54 S4-2 40 82 71S5-2 39 64 100  u_(min) and u_(max) denote minimum and maximum infusionrates, respectively, and R_(in range) the percentage of time that SVVtarget value stayed in the acceptable range once SVV target range wasreached.

Relative Hypovolemia from Vasodilatation: Dogs were made hypotensive byincreasing the inspired concentration of isoflurane (S5-1) or byadministering sodium nitroprusside (S4-1) until mean arterial bloodpressure was less than or equal to 50 mmHg. The target range SVV was setat 13±3% for S4-1 and 5±3% for S5-1. The administration of isoflurane orsodium nitroprusside decreased mean arterial blood pressure andincreased heart rate and either did not change or increased cardiacoutput, respectively (Table 4). SVV increased in both dogs (Table 4).Closed-loop fluid resuscitation increased cardiac output and decreasedSVV in both dogs. Arterial blood pressure increased during fluidadministration in the dog administered sodium nitroprusside (S4-1) butnot in the dog administered isoflurane (S5-1) (Table 4). Total infusedvolumes were 187 ml (nitroprusside: 15 ml/kg) and 265 ml (isoflurane: 28ml/kg).

TABLE 4 Hemodynamic data and performance metrics for the relativehypovolemia study. After Baseline Before Resuscitation Resuscitation CO(L/min) 0.8 I; 1.4 SN 0.8 I; 1.6 SN 1.4 I; 2.0 SN MAP 62 I; 69 SN 45 I;47 SN 35 I; 94 SN (mmHg) HR (bpm) 84 I; 89 SN  87 I; 115 SN  89 I; 126SN SVV (%) 7 I; 9 SN 10 I; 17 SN) 6 I; 8 SN Performance MetricsT_(target) u_(min) u_(max) V_(target) R_(in range) Study (min)(ml/kg/hr) (ml/kg/hr) (ml/kg) (%) S4-1 3 11 67 3 100 S5-1 4 63 73 5 90T_(target) denotes the duration from start of fluid administration torestoration of an acceptable SVV target range, u_(min) and u_(max)denote minimum and maximum infusion rates, respectively, V_(target)denotes total infused volume to reach the acceptable SVV target range,and R_(in range) the percentage of time that SVV stayed in theacceptable range once SVV target range was reached. I = isoflurane; SN =sodium nitroprusside

Relative Hypovolemia and Controlled Hypovolemia: Increasing theisoflurane concentration from 1.5 to 2.5 MAC (S2-1) or administration ofsodium nitroprusside (S2-2) was followed by blood withdrawal (15ml/kg/15 minutes). The sodium nitroprusside infusion rate started at 1mcg/kg/min and was increased to 15 mcg/kg/min. The target range SVV wasset at 13±3%. Absolute hypovolemia (15 ml/kg/15 min) during 2.5 MACisoflurane anesthesia decreased MAP from 60 mmHg before blood withdrawalto 39 mm Hg after blood withdrawal (S2-1). In addition, MAP increasedfrom 39 mmHg to 46 mmHg after a 15-minute stabilization period. Heartrate changed minimally (110 vs. 112 bpm) and cardiac output decreased20% (1.0 vs. 0.8 L/min) after the production of relative hypovolemiacombined with controlled hypovolemia (15 ml/kg/15 min). The SVVincreased from 13% at 1.5 MAC to 21% at 2.5 MAC and then to 41% afterwithdrawal of 15 ml/kg of blood. The SVV decreased to 26% after a15-minute stabilization period. The SVV returned to the target range(13%±3) at 43 minutes (T_(target)) after the administration of 78 ml/kgof LRS. Total infused volume was 573 ml (V_(ratio)=5.4). The maximumfluid administration rate (u_(max)) was 113 ml/kg/hr. Heart ratedecreased (112 to 99) and cardiac output increased to above the baselinevalue (1.0 vs. 1.2) after LRS administration but MAP remained relativelyunchanged (43 mm Hg) until the isoflurane concentration was decreased.

Absolute hypovolemia (15 ml/kg/15 min) during 1.5 MAC and sodiumnitroprusside administration decreased MAP from 113 to 92 mmHg prior toblood withdrawal (S2-2). MAP was 101 mmHg after blood withdrawal. Heartrate changed minimally and cardiac output decreased 25% (1.3 vs. 1.0L/min) after the production of relative hypovolemia combined withcontrolled hypovolemia (15 ml/kg/15 min). The SVV increased from 10% to15% after sodium nitroprusside administration and then to 22% afterwithdrawal of 15 ml/kg of blood. The SVV returned to the target range(13%±3) at 26 minutes (T_(target)) after the administration of 46 ml/kgof LRS. The maximum fluid administration rate (u_(max)) was 108ml/kg/hr. Cardiac output increased to above the baseline value (1.3 vs.2.1) after LRS administration and MAP increased to near the baselinevalue (Table 5). Total infused volume was 400 ml (V_(ratio)=3.7).

TABLE 5 Hemodynamic data and performance metrics for the relativehypovolemia and controlled hypovolemia study. After Baseline BeforeResuscitation Resuscitation CO (L/min) 1.0 I; 1.3 SN 0.8 I; 1.0 SN 1.2I; 2.1 SN MAP  93 I; 113 SN  46 I; 101 SN 40 I; 115 SN (mmHg) HR (bpm)110 I; 134 SN 112 I; 114 SN 99 I; 108 SN SVV (%) 13 I; 10 SN 26 I; 22 SN15 I; 21 SN Performance Metrics T_(target) u_(min) u_(max) V_(target)R_(in range) Study (min) (ml/kg/hr) (ml/kg/hr) (ml/kg) (%) S2-1 43 88113 78 100 S2-2 26 66 108 46 53 T_(target) denotes the duration fromstart of fluid administration to restoration of an acceptable SVV targetrange, u_(min) and u_(max) denote minimum and maximum infusion rates,respectively, V_(target) denotes total infused volume to reach theacceptable SVV target range, and R_(in range) the percentage of timethat SVV stayed in the acceptable range once SVV target range wasreached. I = isoflurane; SN = sodium nitroprusside

The closed-loop fluid resuscitation system used the compartmentalmodeling framework to compute fluid infusion rates. The two-compartmentmodel of the microvascular exchange system involved parameters that aregenerally unknown and different from patient to patient. In addition,the two-compartment model was only an approximation of the fluiddistribution in the body, resulting in modeling error.

The adaptive control fluid resuscitation algorithm uses thecompartmental characteristics of the fluid distribution in the body. Toaddress modeling error and unknown parameters of the compartmental modelgoverning fluid distribution, the adaptive algorithm used a “functionapproximator.” The function approximator was characterized by a set ofparameters, which were continuously estimated by the closed-loop systemin real-time. The closed-loop fluid resuscitation system re-computes thefluid infusion rate periodically. The function approximator used thevalues of infusion rates and SVV measurements to estimate the dynamicsof fluid distribution. The controller performance was evaluated withcomputer simulations on a two-compartment model prior to conducting theanimal study. The results presented are the first attempt to use thedisclosure in live subjects.

Data from this study confirmed that an adaptive closed-loop fluidadministration system based on a compartmental model of fluiddistribution provided targeted goal-directed fluid therapy in dogssubjected to experimental conditions that mimicked clinical scenarios ofabsolute (controlled, uncontrolled), relative hypovolemia or acombination of relative hypovolemia and absolute controlled hypovolemia.Stroke volume variation was restored and maintained to within apreselected normal target range in less than one hour after initiatingfluid administration. Larger volumes of blood loss (40 vs.15 ml/kg)increased the V_(ratio) required to restore SVV to the target range butremained below amounts based upon lactated ringer's solution (LRS)distribution.

The adaptive control algorithm was based on physiology, and theparameters of the model were estimated in real-time. The frameworkprovided a mechanism to account for inter-patient and intra-patientvariability in the fluid resuscitation process.

FIGS. 10 and 11 show the results for 2 canine subjects S1 and S2 (totalof 4 studies) experiencing controlled hemorrhage. FIG. 10 shows changesin filtered SVV (%) versus time, and FIG. 11 shows changes in infusionrate (mL/hr) versus time. The target SVV was 13%. In study S1-1, theinfusion rate dropped from 750 mL/hr to about 400 mL/hr to maintain anSVV of 13%. Once reaching the target SVV (%), the infusion ratefluctuated between 300-400 mL/hr to maintain an SVV of 13% In studyS1-2, the infusion rate started from about 800 mL/hr increased to about1000 ml/hr and decreased to about 850 ml/hr. In study S2-1, the infusionrate started from about 800 mL/hr and in the end reached about 650ml/hr. In study S2-2, the infusion rate started from about 750 mL/hr andin about 30 minutes reached about 500 ml/hr but increased to 750 ml/hr.

FIGS. 12 and 13 shows the results for 3 canine subjects S3, S4, and S5experiencing uncontrolled hemorrhage. FIG. 12 shows changes in filteredSVV (%) versus time, and FIG. 13 shows changes in infusion rate versustime. The target SVV was 13% in studies S3-1 and S4-2 and was 10% instudy S5-2. In study S4-2, the partial automation (clinical decisionsupport) was used where every 1 minute the clinician used fluid ratesrecommended by the system to manually change the infusion rate on thepump. In the other two studies S3-1 and S5-2 the fully automatedclosed-loop system was used. In study S3-1, the infusion rate startedfrom about 600 mL/hr and increased to about1200 mL/hr to drive SVV to13% and then dropped to 750 mL/hr. In study S4-2, the infusion ratestarted from about 750 mL/hr increased to 999 mL/hr and then decreasedto about 600 mL/hr to drive SVV to 13%. In study S5-2, the infusion ratestarted from about 500 mL/hr and fluctuated between 400-600 mL/hr todrive SVV to the target value of 10%.

FIGS. 14 and 15 shows the fluid resuscitation of 2 canine subjects S4and S5 that were hypotensive as a result of administration of sodiumnitroprusside (in S4-1) and increase in the inhalant anestheticisoflurane (in S5-1). In study S5-1, the fully automated closed-loopsystem was used while in study S4-1 the partially automated (clinicaldecision support) system was used where the recommended infusion ratewas displayed every 1 minute to the user and the user changed theinfusion rate on the pump manually. FIG. 14 shows changes in filteredSVV (%) versus time, and FIG. 15 shows changes in infusion rate versustime. The target SVV was 13% in S4-1 and 5% in S5-1. In S4-1, theinfusion rate was started at about 650 mL/hr and decreased to between150-350 mL/hr once the target 13% was reached. In S5-1, the infusionrate started at about 700 mL/hr and was kept close to this value until25 minutes into the study, when the study was terminated as SVVapproached the desired SVV of 5%.

Example 6: Higher-Level Controller

The higher-level controller was designed as a rule-based expert systemand served to:

-   -   i) monitor the lower-level controller (fluid resuscitation        module and/or cardiovascular drug administration module)        function for possible anomalies;    -   ii) monitor the patient's general status and response to fluid        therapy and/or cardiovascular drug administration;    -   iii) in the case of closed-loop mode decide to engage fluid        resuscitation module, cardiovascular drug administration module,        or both, and the timing of engagement of the modules;    -   iv) handle scenarios related to sensor failure or infusion rate        exceeding maximum safe limit;    -   v) modify the lower-level controller (fluid resuscitation module        or cardiovascular drug administration module) states in the case        of clinical decision support if the user disagrees with the        computed infusion rate;    -   vi) provide clinical decision support to address potential        problems; and    -   vii) in clinical decision support mode, notifying the user with        the new infusion rate when the infusion rate needs to be        updated.

Maintaining Infusion Rate in Safe Range. If the computed infusion rateby the lower-level controller (fluid resuscitation module and/orcardiovascular drug administration module) was larger than the maximumsafe rate specified by the user, the higher-level controller reset thelower-level controller associated with unallowable infusion rate, thatis, it reinitialized the internal states of the lower-level controllerincluding function approximator weights (or coefficients) to the defaultvalues (i.e., changed w_(p), w_(q), and x_(c) to their values at t=0).

Warning the User. If the total volume delivered to the patient exceededa set threshold (e.g., 2000 mL or 10,000 mcg), the higher-levelcontroller warned the user of the risk of complications.

Monitoring the Lower-Level Controller. If performance degradation in theclosed-loop system was detected, the higher-level controller notifiedthe user through an audio-visual alarm, and the higher-level controllerstopped the lower-level controller. Performance degradation was definedas: i) a rapid change in weights (or coefficients) of the functionapproximator, that is,

$\frac{d{❘W❘}}{dt} > {threshold}$

(e.g., 0.1, or 1, 10 etc.); or ii) the number of resets of thelower-level controller by the higher-level controller exceeding athreshold value (e.g., 1, 2, 3, 4, etc.), or iii) the absolutedifference between the measured value (e.g., SVV or mean arterialpressure) and the target value did not decrease in a period of time setby user while the infusion was continuously increased. In case of sensorfailure or unavailability of measurements, the higher-level controllerdisabled the lower-level controller and set the infusion rate to abackup the infusion rate set by the user.

Deciding When to Engage Fluid Resuscitation and Cardiovascular DrugAdministration Modules. In certain scenarios such as sepsis, it ispreferable to provide fluid resuscitation first, and if unsuccessful inachieving an acceptable condition, administer a cardiovascular drug suchas a vasopressor. The higher-level controller first engaged the fluidresuscitation module and monitored the patient. After a period of timewhen a clinically relevant hemodynamic variable (e.g., mean arterialpressure) was not improved in spite of fluid resuscitation (e.g., themean arterial pressure was not in the acceptable range of 65-80 mmHgafter 30 minutes), the higher-level controller engaged thecardiovascular drug administration module to administer a vasopressor.In some embodiments, the clinician instructed the higher-levelcontroller to engage the cardiovascular drug administration module whilethe fluid resuscitation module was already running. In some embodiments,the clinician instructed the higher-level controller to engage the fluidresuscitation module while the cardiovascular drug administration modulewas already running. In this scenario, stroke volume variation was notimproved by only administering a cardiovascular drug (e.g., avasopressor) and the higher-level controller engaged the fluidresuscitation module.

FIG. 16 illustrates the components of the higher-level controller forthe closed-loop fluid resuscitation and/or cardiovascular drugadministration system. The higher-level controller can monitor the fluidresuscitation module and/or the cardiovascular drug administrationdepending on whether the system is used for fluid resuscitation only,for cardiovascular drug administration only, or combined fluidresuscitation and cardiovascular drug administration.

In the clinical decision support system case, the lower-level controller(fluid resuscitation module or cardiovascular drug administration moduleor both) sent newly computed infusion rate to the higher-levelcontroller. Specifically, we considered 3 scenarios: i) fluidresuscitation module only; ii) cardiovascular drug administration moduleonly; and iii) fluid resuscitation module and cardiovascular drugadministration module working concurrently. In each scenario, thelower-level controller sent newly computed infusion rate to thehigher-level controller. The higher-level controller compared the newrate with the last user approved rate (i.e., for a fluid resuscitation,the newly computed fluid infusion rate was compared with the lastuser-approved fluid infusion rate, and for cardiovascular drugadministration, drug infusion rate was compared with the lastuser-approved drug infusion rate).

If the difference between the new infusion rate and the lastuser-approved rate was less than the threshold value (e.g., 25% of thelast approved rate), then the infusion rate was not changed, the userwas not notified, and the lower-level controller continued itsoperation. If the difference between the new infusion rate and the lastuser-approved rate was higher than some threshold (e.g., 25% of the lastapproved rate), then the recommended infusion rate was displayed to theuser through the graphical user interface. If the user accepted theinfusion rate, the higher-level controller allowed the lower-levelcontroller to continue its operation and the infusion rate was updatedto the new rate. However, if the user changed the recommended infusionrate to a different value, the higher-level controller reset thecontroller and set the weights of the function approximator such thatthe infusion rate computed by the lower-level controller matched theinfusion rate entered by the user. The infusion rate was also updated tothe rate provided by the user. Given the user specified infusion rate,the weights of the function approximator was chosen such that

w _(q,new)(0)=w _(q)(0)

w _(p,new) ^(T)(0)P(z(0))=(new infusion)(1+w _(q) ^(T)(0)Q(z(0)))

FIG. 17 illustrates the components of the higher-level controller forthe clinical decision support case.

Example 7: Computer Simulations for Vasopressor Administration

Adaptive control frameworks were used to simulate cardiovascular drug(vasopressor) administration of a 70 kg patient experiencing sepsis andthe associated hypotension. The goal was to maintain the mean arterialpressure at 65. A Δt of 0.1 minute (6 seconds) was used for thesimulations and β₁=6e−5, β₂=13e−6, and n_(node)=8. Only the vasopressorwas administered to maintain a mean arterial pressure of 75 mmHg. Thepatient model involved a cardiovascular model to model hemodynamics anda compartmental model to model fluid distribution.

FIG. 18 shows mean arterial pressure (MAP) versus time. The target MAPwas 75 mmHg, and the 65-75 mmHg region is highlighted on the graph. MAPstarted at below 60 mmHg, and changes with the introduction ofvasopressor epinephrine. The MAP increased to the target value of 75mmHg.

FIG. 19 shows infusion rates computed by the adaptive control framework.The initial infusion rate was chosen by the user to be 0.12 mcg/kg/minat t=8 (start of the vasopressor administration). The infusion rategradually increased and then started to decrease as MAP started toapproach the target MAP of 75 mmHg reaching a low infusion rate of 0.85mcg/kg/min. The infusion rate then started to gradually increase tomaintain MAP of 75 mmHg.

Example 8: Computer Simulations for Fluid Administration Using MeanArterial Pressure

Adaptive control frameworks were used to simulate fluid resuscitation ofa 70 kg patient with hypotension as a result of sepsis. The goal was tomaintain the mean arterial pressure at 75 mmHg. A Δt of 0.1 minute (6seconds) was used for the simulations and β₁=0.02, β₂=0.04, andn_(node)=8. The patient model involved cardiovascular modeling to modelhemodynamics and a compartmental model to model fluid distribution.

FIG. 20 shows mean arterial pressure (MAP) versus time. The target MAPis 75 mmHg and the 65-75 mmHg region is highlighted on the graph. MAPstarts at approximately 45 mmHg, and changes with the introduction ofcrystalloid fluid. The MAP increases to the target value of 75 mmHg.

FIG. 21 shows infusion rates computed by the adaptive control framework.The initial infusion rate was chosen was approximately 140 mL/min. Theinfusion rate gradually increased to 160 mL/min and then decreased toaround 80 ml/min.

Example 9: Computer Simulations for Fluid Administration andCardiovascular Drug Administration

Adaptive control frameworks were used to simulate fluid resuscitationand cardiovascular drug (vasopressor epinephrine) administration for a70 kg patient with hypotension as a result of sepsis. The goal was tomaintain the mean arterial pressure at 75 mmHg and stroke volumevariation (SVV) of 12%. A Δt of 0.1 min (6 seconds) was used for thesimulations and β₁=0.02, β₂=0.04, and n_(node)=8 for the fluidresuscitation module and β₁=6e−5, β₂=13e−6, and n_(node)=8 for thecardiovascular drug administration module. The simulation involvedcrystalloid fluid and epinephrine (vasopressor). The fluid resuscitationmodule used SVV data to compute fluid infusion rates, and thecardiovascular drug administration module used mean arterial pressure(MAP) to compute the vasopressor infusion rates. The higher-levelcontroller first engaged the fluid resuscitation module to provide fluidinfusion. After 30 minutes, the higher-level controller engaged thecardiovascular drug administration module as mean arterial pressure wasnot improved after fluid infusion. The patient model involvedcardiovascular modeling to model hemodynamics and compartmental model tomodel fluid distribution. The start of simulation is when the patientcondition rapidly deteriorates.

FIG. 22 shows stroke volume variation (SVV (%)) versus time. The targetstroke volume variation was 12%. The SVV (%) started at about 18%, andwas reduced to 10% after fluid resuscitation. SVV momentarily increaseddue to the administration of epinephrine (a transient vasodilatoryeffect). In the end of the simulation, SVV was approximately 11% andremained close to the target SVV value of 12%.

FIG. 23 shows fluid infusion rates computed by the fluid resuscitationadaptive control framework. The infusion rate started at approximately130 mL/min and was reduced to 40 mL/min after SVV was at an acceptablerange. The sudden increase in SVV at t=30 min resulted in an increase ininfusion rate which then reduced back to 40 mL/min after SVV wasreduced.

FIG. 24 shows mean arterial pressure (MAP) versus time. The target MAPwas 75 mmHg and the 65-75 mmHg region is highlighted on the graph. MAPdropped to 50 mmHg as the patient condition deteriorated. After 30minutes, when the cardiovascular drug administration module was engagedby the higher-level controller, MAP started to increase and approachedthe set value of 75 mmHg. At the end of the simulation, MAP wasapproximately 70 mmHg and remained close to the target MAP value of 75mmHg.

FIG. 25 shows vasopressor infusion rates computed by the cardiovascularadministration adaptive control framework. The initial infusion rate waschosen to be approximately 0.12 mcg/kg/min. After a slight increase, therate decreased to approximately 0.9 mcg/kg/min and then stabilizedaround 0.12 mcg/kg/min as MAP is maintained close to 70 mmHg.

Example 10: Fluid Resuscitation and Cardiovascular Drug AdministrationSystem Implemented on Hardware

A hardware platform was developed to implement the fluid resuscitationsystem and the cardiovascular drug administration system. The system iscomposed of a processing module and an associated touchscreen. Theprocessing module is able to receive data from a hemodynamic monitor(invasive or non-invasive measurement) or a blood pressure module(either invasive measurement through a pressure transducer connected toan arterial line or non-invasive measurement) through a wiredconnection. In addition, the processing module is able to send real-timeinfusion rate data through a wired connection to an infusion pump. Thetouchscreen is used for displaying graphs such as received measurementsover time and infusion rate over time. The main dashboard also displayscurrent measurement, current infusion rate, and total volume offluid/drug infused. The touchscreen allows the user to specify differentparameters required by the system. For example, the user sets the targetmeasurement value, initial infusion rate, backup infusion rate (in caseof missing sensor data, the closed-loop system is disengaged andtransitions to backup infusion rate until the user takes over) maximuminfusion rate and other variables. In the case of clinical decisionsupport, the touchscreen is used to communicate the new infusion ratevalue to request user's approval or give the user the ability to modifythe rate. Once the user approves the infusion rate, the processingmodule updates the infusion rate of the infusion pump to the infusionrate approved by the user.

FIG. 26 is a system diagram of an embodiment of the hardware platform.

FIG. 27 is a block diagram illustrating an embodiment of the apparatusfor displaying infusion therapy information for optimizing infusiontherapy. FIG. 28 depicts an embodiment of the apparatus for displayinginfusion therapy information for optimizing infusion therapy. Theapparatus comprises a memory, a display, and one or more processor inoperable communication with the memory and the display. The processor iscapable of receiving sensor-obtained hemodynamic measurements of asubject from a hemodynamic monitoring device. The processor is furthercapable of issuing a prompt to the display upon determining anappropriate notification message and an appropriate change in infusionrate recommendation message, which are implicated upon detection of achange in infusion therapy. The detection of a change in infusiontherapy is based at least on hemodynamic measurements of a subject, anactive infusion rate stored in the memory, and a background infusionrate computed by a lower-level controller.

In some embodiments, an active infusion rate is a last user-approvedinfusion rate. The last-approved infusion rate can be a last infusionrate that was recommended through a prompt and accepted by a user. Inother embodiments, an active infusion rate can be an infusion rateobtained from an infusion pump that is actively administering fluid intoa subject. A background infusion rate is an infusion rate that uponupdates to its value does not actively change the infusion rate of fluidor drug administered to a subject, but rather it updates in thebackground. In some embodiments, a background infusion rate is computedby a lower-level controller. In other embodiments, the backgroundinfusion rate can take on the value of an active infusion rate. This maybe through mechanisms such as a rejection of a recommended infusion rateprompted to a user which permits the user to manually override therecommendation with a desired infusion rate. In this example, thedesired infusion rate would become an active infusion rate and thebackground infusion rate, at least momentarily, would take on the valueof this set desired infusion rate.

An appropriate notification message can alert a user that a newrecommended infusion rate is available. In other embodiments, thenotification message can alert a user that subject being treated withthe infusion therapy is not improving based upon hemodynamicmeasurements. In yet another embodiment, the notification message canalert a user of a failure in receiving hemodynamic measurements from amonitoring device. In other embodiments, this notification message canalert a user of a failure in administering fluid, for instance, due to astatus message received from an infusion pump. In other embodiments, thenotification message can alert the user that received hemodynamicmeasurements exceed, equal, or drop below some threshold.

An appropriate change in infusion rate recommendation message can be arecommendation to increase or decrease the current active infusion rate.In other embodiments, an appropriate change in infusion raterecommendation message can be a specific value for infusion rate (e.g.700 mL/hr, 300 mL/hr, 0 mL/hr). In one embodiment, this specific valuecan be 0 mL/hr, that is, to stop infusion of fluids or drugs to apatient, if an associated notification message alerts the user that thehemodynamic condition of a subject is not improving; in anotherembodiment, the recommendation to stop infusion of fluids or drugs maybe due to an associated notification message that alerts the user thatsome hemodynamic measurement exceeds or drops below some threshold.

In some embodiments, the notification message is generated only if theabsolute difference between the active infusion rate and the backgroundinfusion rate is larger than a pre-determined threshold. In case theabsolute difference between the active infusion rate and the backgroundinfusion rate is less than the pre-determined threshold then the valueof the background infusion rate is ignored and the lower-levelcontroller continues with computing new background infusion rates untilthe criterion for notifying the user is met. In some embodiments, thepre-determined threshold is a percentage of the active infusion rate(e.g, 1%, 2%, 5%, 10%). In other embodiments, the pre-determinedthreshold is an absolute value (e.g., 0.001 ml/hr, 0.1 ml/hr, 1 ml/hr,10 ml/hr, 100 ml/hr, 1000 ml/hr).

Referring again to FIG. 27 , the display can be a touchscreen-baseddisplay in which a user can interact with any prompt through touchgestures. In other embodiments, the display can be a non-touchscreendisplay and the user can interact with any prompt with suitable inputdevices, such as physical buttons, a mouse/trackpad, a keypad/keyboard,etc.

A detection of a change in infusion therapy can be performed by thehigher-level logic-based controller based upon the performance criteriadiscussed earlier. In some embodiments, the detection of a change ininfusion therapy occurs when an active infusion rate and a backgroundinfusion rate differ in value by some percentage (e.g. 5%, 10%, 12%,etc.) of the active infusion rate, some percentage of the backgroundinfusion rate, or some percentage of the average of the active andbackground infusion rate; in other embodiments, the difference can besome absolute value (e.g. −50 mL/hr, 50 mL/hr, 100 mL/hr, etc.) whichwould trigger the detection.

Referring to FIG. 28 , in some embodiments of the apparatus, uponissuance of a prompt 2810 that contains a slide to accept element or tapto reject element to the display containing a notification message 2820and a change in infusion rate recommendation message 2830, there is alimited time for the user to respond with an acceptance or a rejection.If the user wishes to manually override the recommended infusion ratewith a desired infusion rate, an infusion rate can be set with infusionmeter slider 2840. However, if the user rejects using thereject/discard/trash button of 2810 or if the timer 2800 expires, theactive infusion rate remains unchanged and the background infusion rateis set to the same value as the unchanged active infusion rate. If therecommended infusion rate is not accepted (e.g. due to manual override,rejection, or timer expiration), the higher-level logic controllerresets at least one element of the set of weights of the lower-levelcontroller to a new value based at least in part on the backgroundinfusion rate.

Fluid and/or Cardiovascular Drug Administration with Pre-Approved Rangesof Infusion Rates by the User

The presented disclosure can be implemented in a way to minimizeunnecessary interactions with the user regarding changes in infusionrates, which the user may deem acceptable or negligible. The advantageof this implementation is that the clinical decision support system hasa specific level of autonomy to automatically change infusion rates aslong as the infusion rates are within the pre-approved range specifiedby the user. In some embodiments, the clinical decision support systemcan be coupled to an internal or external infusion pump.

In some embodiments, the user can enter pre-approved ranges of infusionrates into the system with the intent that the system is authorized tochange infusion rates automatically without requesting the user toapprove the changes as long as the infusion rates fall within thepre-approved ranges. In some embodiments, the system automaticallychanges the infusion rate by instructing the pump and updating infusionrate on the graphical user interface as long as the new infusion ratesare within the pre-approved infusion rates. In some embodiments, apre-approved range can be entered using a lower limit and an upper limit(e.g., 50-100, 100-500, 500-1000 ml/hr).

In some embodiments, the approved range can be entered based on the lastuser-approved infusion rate. In this case, the user authorizes theclinical decision support system to internally approve infusion ratesthat are within a set distance (specified by the user) from the lastuser-approved infusion rate. For example, the user may authorize apre-approved range of 500 ml/hr, in which case if the last user-approvedinfusion rate is 750 ml/hr the system is authorized to change theinfusion rate as long as the new infusion rates are within 250 ml/hr to1,250 ml/hr. In some embodiments, the user can specify a percentagechange as a pre-approved range. For example, the user can approve a 10%change as a pre-approved range. In this case, if, for example, thelast-approved infusion rate is 1,000 ml/hr, then the clinical decisionsupport system can internally approve new infusion rates in the range900 ml/hr to 1,100 ml/hr without requesting user's approval.

In some embodiments, the higher-level logic-based controller willcompare the new infusion rate received from the lower-level controllerwith the pre-approved ranges. If the new infusion rate is within thepre-approved range (that is the new infusion rate is greater than orequal to the lower limit and less than or equal to the upper limit),then the higher-level logic can instruct the infusion pump to update theinfusion rate to the new infusion rate value. However, if the newinfusion rate falls outside the pre-approved range, the user is notifiedusing the graphical user interface, where the user would approve,reject, or modify the new infusion rate.

Referring to FIG. 29 , a flow chart of the process is presented. Theprocess starts by the user entering the pre-approved infusion rates intothe system using the user interface. The lower-level controller computesnew infusion rates based at least in part on hemodynamic measurements.The higher-level logic-based controller receives the newly computedinfusion rates from the lower-level controller and determines whetherthe new infusion rate is within the pre-approved range. If so, itinstructs the pump to update the infusion rate. Otherwise, it asks theuser to approve, reject, or modify the new infusion rate.

Alarm Function to Prevent Under- or Over-Administration of Fluid and/orDrug

The hierarchical control system described in this disclosure can be usedfor monitoring therapy to a subject in order to flag cases where thesubject would receive lower or higher than expected infusion of a fluidor cardiovascular drug. Both fluid and cardiovascular drugover-administration or under-administration is detrimental to thepatient, and hence, a system that continuously monitors therapyincluding the infusion rate and patient's hemodynamic measurements andalerts the user if the patient is receiving more than expected or lessthan expected fluid and/or cardiovascular drug is desirable. In someembodiments, the system continuously monitors the patient's hemodynamicmeasurements, the type of therapy or therapies, and the infusion rate orinfusion rates of the therapy or therapies, and notifies the userthrough a user interface if the patient is getting more than expected orless than expected fluid and/or cardiovascular drug. In some embodiment,this is implemented in a hemodynamic patient monitor at the bedsidereceiving information from the pump. In some embodiments, this isimplemented as a software application as part of a remote patientmonitoring platform, where information from hemodynamic monitors andinfusion pumps are continuously analyzed and cases ofover-administration or under-administration of fluid and/orcardiovascular drug is detected. In some embodiments, data from multiplehemodynamic monitors and infusion pump for different patients are allsent to the same remote location for analysis. In some embodiments, thesystem is implemented inside an infusion pump. In this case, theinfusion pump receives hemodynamic measurement data from a hemodynamicmonitor or other source.

Referring to FIG. 30 , in some embodiments, the lower-level controllerruns in the background and computes new infusion rates periodically. Thenewly computed infusion rates are kept in the background, and analyzedby the higher-level logic-based controller. The internal states of thelower-level controller are initialized such that the starting infusionrate generated by the lower-level controller matches the actual infusionrate specified by the user. In some embodiments, the lower-levelcontroller uses a function approximator with a set of weights, where theweights are determined in a way such that the initial infusion rategenerated by the lower-level controller matches the actual infusion ratespecified by the user. In some embodiments, the function approximator isa neural network. As an example, given the user specified infusion rate,the weights of the function approximator was chosen such that

w _(q,new)(0)=w _(q)(0)

w _(p,new) ^(T)(0)P(z(0))=(pump infusion rate)(1+w _(q) ^(T)(0)Q(z(0)))

As discussed above, after initialization, the lower-level controllerperiodically computes a new infusion rate in the background and sendsthe background infusion rate to the higher-level logic-based controller.The higher-level controller records the current value of the backgroundinfusion rate and the current value of the actual infusion rate in amonitoring data base. A monitoring module periodically analyzes thebackground infusion rate and the actual infusion rate. If the differencebetween the background infusion rate and the actual infusion rate ismore than a set threshold (e.g., the difference between the rates are1%, 5%, 10% etc. more or less than the actual infusion rate), then themonitoring module sends a command to the higher-level logic controllerto notify the user of over-administration or under-administration. Thenotification could be in the form of an audio/visual alarm or bygenerating a number or index indicating the difference between theactual infusion rate and the background infusion rate.

In some embodiments, the monitoring module sends a command to thehigher-level logic-based controller to notify the user when itidentifies at least one entry in the monitoring database with anabsolute value of difference between actual infusion rate and backgroundinfusion rate greater than a set threshold. In some embodiments, themonitoring module sends a command to the higher-level logic-basedcontroller to notify the user when it identifies in the monitoringdatabase at least two consecutive entries or two non-consecutive entriesin a set time interval with an absolute value of difference betweenactual infusion rate and background infusion rate greater than a setthreshold.

In some embodiments, alarm system is implemented on an infusion pump,where the infusion pump periodically receives data from a hemodynamicmonitor. In some embodiments, the audio and/or visual alarm can begenerated on the infusion pump using a graphical user interface. In someembodiments, a dedicated light of a specific color (e.g., red, oryellow, or blinking red, blinking yellow) could turn on accompanied byan audio alarm to indicate under-administration or over-administrationof fluid and/or cardiovascular drug.

1. A system for fluid or drug administration comprising: a) a monitoring module configured to receive hemodynamic measurements of a subject from at least one medical monitoring device attached to the subject; b) a controller module configured to: (i) estimate a current value of one or more physiological parameters of the subject based at least in part on the hemodynamic measurements; (ii) compute an updated infusion rate based at least in part on the estimate of the current value of one or more physiological parameters of the subject and the received hemodynamic measurements; and (iii) communicate the updated infusion rate to an infusion pump; and c) a graphical user interface to receive a start and/or stop command from a user to start and/or stop the controller module.
 2. The system of claim 1, wherein the controller module is further configured to approximate at least one unknown function describing distribution of a fluid and/or drug in the body of the subject based at least in part on the received hemodynamic measurements.
 3. The system of claim 1, wherein the updated infusion rate is computed based at least in part on an initial infusion rate set by the user by way of the graphical user interface.
 4. The system of claim 1, wherein the controller module is further configured to: (a) verify whether the updated infusion rate meets infusion rate requirements; and (b) verify whether a performance criterion is violated.
 5. The system of claim 1, wherein the controller module is further configured to disengage based on violation of a performance criterion.
 6. The system of claim 1, wherein the at least one unknown function describing distribution of a fluid and/or drug in the body of the subject is approximated using a function approximator.
 7. The system of claim 6, wherein the function approximator is a neural network with sigmoidal basis functions.
 8. The system of claim 1, wherein the user interface is further configured to receive a measurement target value from the user.
 9. The system of claim 1, wherein the user interface is further configured to receive a range of safe infusion rates from the user.
 10. The system of claim 1, wherein the user interface is further configured to display the updated infusion rate.
 11. The system of claim 1, wherein the user is notified if at least one infusion therapy performance criterion is violated.
 12. The system of claim 1, wherein the updated infusion rate is updated to a backup infusion rate if the hemodynamic measurements is unavailable.
 13. The system of claim 1, wherein the hemodynamic measurements of the subject comprises the subject's blood pressure, heart rate, stroke volume variation, urine output rate, urine output, central venous pressure, pulse pressure variation, dynamic arterial elastance, systolic pressure variation, mean arterial pressure, systolic pressure, diastolic pressure, cardiac output, cardiac index, systemic vascular resistance, or stroke volume.
 14. A method for fluid and/or cardiovascular drug administration, the method comprising: receiving from a sensor hemodynamic measurements of a subject by a controller, wherein the controller comprises an estimator to estimate a current value of one or more physiological parameters of the subject based at least in part on the hemodynamic measurements; computing an updated infusion rate based at least in part on the estimate of the current value of one or more physiological parameters of the subject and the received hemodynamic measurements and a target measurement value set by a user; notifying the user and disengaging the controller if at least one performance criterion is violated by dropping below or exceeding a set threshold; and administering the fluid and/or cardiovascular drug at the new infusion rate to the subject.
 15. The method of claim 14, wherein the controller further comprises a function approximator to approximate at least one unknown function describing distribution of a fluid and/or drug in the body of the subject based at least in part on the received hemodynamic measurements.
 16. The method of claim 15, wherein the updated infusion rate is computed based on at least one parameter of the function approximator.
 17. The method of claim 15, wherein the function approximator is a neural network with sigmoidal basis functions.
 18. The method of claim 14, wherein the performance criterion is an infusion therapy performance criterion.
 19. The method of claim 14, wherein the hemodynamic measurements of the subject comprises the subject's blood pressure, heart rate, stroke volume variation, urine output rate, urine output, central venous pressure, pulse pressure variation, dynamic arterial elastance, systolic pressure variation, mean arterial pressure, systolic pressure, diastolic pressure, cardiac output, cardiac index, systemic vascular resistance, or stroke volume.
 20. The method of claim 14, wherein the updated infusion rate is computed based at least in part on an initial infusion rate set by the user. 